Java EE 6 vs. pilha Spring 3 [fechado]


90

Estou começando um novo projeto agora. Tenho que escolher tecnologias. Preciso de algo leve, sem EJB ou Seam. Por outro lado, preciso de JPA (Hibernate ou alternativo) e JSF com IceFaces.

Você acha que essa pilha no Spring 3 implantado no Tomcat é uma boa escolha? Ou um aplicativo da web Java EE 6 poderia ser melhor? Receio que o Java EE 6 seja uma tecnologia nova, ainda não bem documentada. O Tomcat parece ser mais fácil de manter do que o Glassfish 3.

Qual a sua opinião? Você tem alguma experiência?


8
Eu escolheria primefaces.org em vez de IceFaces se você quiser luz. É muito mais rápido e uma API mais enxuta.
Shervin Asgari

1
No momento, há apenas Glassfish fornecendo JEE6. A Resin está implementando lentamente o perfil da web JEE6 , o que pode ser suficiente para você, dependendo do que você precisa.
Thorbjørn Ravn Andersen,

3
@ Thorbjørn Você pode usar o Perfil da Web GlassFish v3 se quiser apenas o perfil da web.
Pascal Thivent

@Pascal, foi para o detalhe que em breve haverá uma alternativa ao Glassfish para obter JEE6 se você puder conviver com o perfil da web (eu posso), para não dizer que o Glassfish não pode.
Thorbjørn Ravn Andersen,

@ Thorbjørn Esqueci de remover o @ Thorbjørn :) O comentário era destinado ao OP, que parece estar assumindo que usar o GFv3 "full-stack" é a única opção.
Pascal Thivent

Respostas:


101

Preciso de algo leve, sem EJB ou Seam.

Você se importaria de explicar o que torna os EJBs pesados ​​desde o EJB3? Você percebe que não estamos mais em 2004? Eu realmente gostaria de ler sua definição de luz e seus argumentos (e atualizarei minha resposta com prazer porque tenho certeza de que teria algumas coisas sólidas a dizer).

Por outro lado, preciso do JPA (Hibernate ou alternativo) e do JSF com IceFaces.

O Java EE 6 Web Profile que inclui JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... seria perfeito para isso e você pode usar o GlassFish v3 Web Profile para executar um aplicativo construído com o Java EE 6 Web Profile .

Você acha que essa pilha no Spring 3 implantado no Tomcat é uma boa escolha? Ou um aplicativo da web Java EE 6 poderia ser melhor?

Bem, eu gosto da idéia de executar o meu código em uma plataforma não-proprietária (Java EE), em vez de em um recipiente de propriedade (Primavera). E eu acho que Java EE 6 é bom o suficiente (e isso é um eufemismo, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI arrasar). Observe que eu era um cético em relação ao JSF, mas dei uma segunda olhada e o JSF 2.0 com CDI é tão diferente que nem posso comparar. E se você não olhou para CDI, deixe-me dizer que é demais.

Receio que o Java EE 6 seja uma tecnologia nova, ainda não bem documentada.

Java EE parece muito bem documentado para mim. Isso soa como reivindicação gratuita. E, acredite ou não, eu começar a encontrar Primavera ficando complicado enquanto Java EE ficando mais fácil.

O Tomcat parece ser mais fácil de manter do que o Glassfish 3.

Você tentou alguma coisa? Você enfrentou algum problema em particular? Novamente, isso soa como uma reivindicação gratuita.


2
Estou atrás de um grande projeto de avaliador desenvolvido com EJB3.0 + Seam no JBoss com Drools, GraniteDS e alguns mais. Eu concordo Seam rocks! Mas eu gastei 50% do desenvolvimento na reimplantação, reiniciando servidores, erros de implantação, limpando diretórios temporários, etc. Por outro lado, o desempenho do JBoss Tools foi muito ruim (quero dizer, realmente - ctrl + espaço e 10s travar). Isso realmente me desencoraja a usar JEE6 que parece emprestado do framework Seam. Quanto ao servidor, não quero pensar em conecion pools, jndi, jms, jmx, ear deplyment. Preciso de algo para colocar o WAR e executar em segundos.
Piotr Gwiazda

6
@peperg Gaving King é o líder de especificações do CDI (Weld sendo o RI), então você encontrará semelhanças entre Seam e CDI. Mas CDI! = Seam, Java EE 6! = Seam, sua percepção está errada. Talvez tente o GlassFish v3 Web Profile, você ficará surpreso (e uma vez que o pool de conexão definido, não há muito com que se preocupar).
Pascal Thivent

8
O que há com as pessoas dizendo que os EJBs são pesados? Estou usando o EJB v3.1 e eles são simplesmente pojos anotados. Quando eles dizem pesado, eles querem dizer desempenho ou o quê?
arg20

13
@ arg20 - Essa é de fato a grande questão e Pascal pede com razão para explicar o que o termo "pesado" (ou "leve") significa neste contexto. O mais provável é que seja um resquício da velha rixa entre Spring e EJB. No início, EJB1 e 2 eram conceitualmente pesados. Uma ênfase exagerada em beans remotos e com estado, um descritor de implantação XML ridiculamente detalhado e uma quantidade totalmente insana de interfaces necessárias para serem implementadas deram a eles uma reputação muito ruim. Com o EJB3 (2006), isso mudou completamente, mas as pessoas que deixaram o EJB em 2004 para a primavera às vezes ainda pensam que é 2004 e o EJB2 é o mais recente.
Arjan Tijms

7
Observe que na página sobre do Spring diz "Acreditamos que: J2EE deve ser mais fácil de usar". Observe que eles usam o termo "J2EE" e não "Java EE", que é o nome correto desde o lançamento do Java EE 5 (eu acho). Isso diz muito sobre eles ...
Vítor E. Silva Souza

32

Não usei o JavaEE6.

No entanto, fui espancado o suficiente por todas as versões anteriores de JavaEE e EJBs que não vou confiar até que ele se estabeleça como o padrão de fato, não apenas o padrão de jure. No momento, o Spring ainda é o padrão de fato.

Engane-me uma vez, que vergonha. Engane-me duas vezes, que vergonha. Engane-me três vezes, EJB.

Alguns dirão que o Spring é proprietário. Eu diria que as implementações do fornecedor das especificações JavaEE foram tão proprietárias, se não mais.

Recentemente, passei por uma grande conversão de mover vários aplicativos Java do JBoss para o Weblogic. Todos os aplicativos Spring / Hibernate foram portados sem nenhuma modificação, porque eles tinham todas as bibliotecas necessárias integradas. Todos os aplicativos que usaram JPA e EJB e JSF foram um desastre para portar. Diferenças sutis nas interpretações de JPA, EJB e JSF entre appservers causavam todos os tipos de bugs desagradáveis ​​que demoravam uma eternidade para serem corrigidos. Mesmo algo tão simples como a nomenclatura JNDI era completamente diferente entre os AppServers.

Spring é uma implementação. JavaEE é uma especificação. Essa é uma diferença ENORME. Eu preferiria usar uma especificação SE a especificação fosse 100% hermética e não desse absolutamente nenhuma margem de manobra na maneira como os fornecedores implementam essa especificação. Mas a especificação JavaEE nunca foi essa. Talvez JavaEE6 seja mais hermético? Eu não sei. Quanto mais você pode empacotar em seu WAR, e quanto menos você depender de bibliotecas AppServer, mais portável seu aplicativo será, e essa, afinal, é a razão de eu usar Java e não Dot-NET.

Mesmo SE a especificação fosse rígida, seria bom poder atualizar o appserver sem ter que atualizar todas as minhas pilhas de tecnologia em todos os meus aplicativos junto com ele. Se eu quiser atualizar do JBoss 4.2 para o JBoss 7.0, devo considerar o impacto da versão mais recente do JSF em todos os meus aplicativos. Não preciso considerar o impacto em meus aplicativos Spring-MVC (ou Struts).


1
Exatamente, esse é um ótimo raciocínio.
Palesz

1
Eu concordo com esse raciocínio, muitos problemas que enfrentei foram com dependências na implementação de uma especificação por um contêiner. Significativamente menos dor de bibliotecas incorporadas. Difícil de argumentar, fora da preferência filosófica de uma especificação.
Peter Porter

Raciocínio maravilhoso. No entanto, essa é a sua experiência mesmo após o JEE 6? Eu entendo que as implementações de especificações do App Server ainda podem ser uma dor - portanto, a mesma especificação implementada pelo App Server 1 pode ser simples e eficiente, mas não para o App Server 2
Soumya

1
+1. além disso, o servidor de aplicativos muda de acordo com a programação de Operações, onde a primavera / hibernação está sob o controle dos desenvolvedores. em um ambiente de grande empresa, atualizar o appserver é um negócio muito maior.
Nathan Hughes

Eu realmente não entendi o ponto sobre Dot-Net. É tão proprietário quanto o Spring e é desenvolvido por um único fornecedor que é a Microsoft. Pode ser explicado, por favor?
user1339260

23

Não importa. O Java EE 6 é bom o suficiente e, por causa dos perfis lá, não é "pesado" - você apenas usará o perfil da web.

Pessoalmente, prefiro a primavera. Mas estou ficando sem argumentos racionais contra o Java EE 6 :)

(Como fui lembrado por um comentário - você pode querer experimentar RichFaces , bem como ICEfaces e / ou PrimeFaces - dependendo de quais componentes você precisa).


1
Portanto, a questão é: "Faz sentido usar o Glassfish Application Server full-stack apenas para usar o perfil da web"?
Piotr Gwiazda,

1
@peperg Use o Perfil da Web GlassFish v3 se quiser apenas o perfil da web, veja minha resposta.
Pascal Thivent

Eu postei alguns argumentos aqui stackoverflow.com/questions/2822812/spring-3-0-vs-j2ee-6-0/… , em vez retirados do ponto de vista "como colocá-lo em produção". Então, talvez isso preencha um pouco sua reserva de argumentos.
Oliver Drotbohm

@peperq, JBoss 6 foi lançado durante o feriado.
Thorbjørn Ravn Andersen

17

Recentemente, uma de minhas atribuições de cliente envolveu a avaliação de Spring Stack Vs Custom framework stack Vs a Java EE Standards. Depois de um mês de avaliação e prototipagem, eu não estava apenas feliz, mas impressionado com o conjunto de recursos do Java EE 6. Para qualquer nova arquitetura de projeto "empresarial" em 2011 e daqui para frente, eu escolheria Java EE 6 e extensões potenciais como Seam 3 ou o próximo projeto de extensões Apache JSR299. A arquitetura Java EE 6 é simplificada e incorpora o melhor de muitas ideias de software livre que evoluíram nos últimos anos.

Considere os seguintes recursos prontos para uso: Gerenciamento de eventos, contextos e DI, interceptores, decoradores, serviços da Web RESTful, teste integrado com contêiner incorporável, segurança e muito mais.

A maioria dos meus resultados é publicada em meu blog explicando os conceitos-chave do Java EE 6 que você pode achar úteis.

Obviamente, não existe uma regra rígida e rápida para a escolha de uma estrutura. Java EE 6 poderia ser bem inchado para "sites" mais simples que não requerem um estado de sessão de conversação rico. Você também pode escolher Grails ou Play! Estrutura. Mas, para aplicativos da web de conversação, não consigo ver um argumento melhor de porque o Java EE 6 não é uma boa opção.


Java EE 6 é extremamente lento, o perfil da web glassfish e glassfish é muito lento para começar a compará-los com jetty / tomcat / qualquer coisa. O teste, o contêiner embutido também é muito lento.
Palesz

15

Agora, depois de algum tempo, tenho experiência com pilhas:

  • Java EE 5 + Seam + GraniteDS + Flex
  • Spring 3 + Vaadin (no GWT)
  • Spring 3 + JSF 2.0 (PrimeFaces)

Minhas conclusões são:

  • Spring 3 é muito mais simples do que Seam (quase Java EE 6) e roda em Tomcat e Jetty! (Jetty para desenvolvimento com o plugin maven é um trasure).
  • Eu amo Flex (na verdade eu fui um desenvolvedor Flex por muito tempo, então sou preconceituoso) e se você precisa de uma interface rica e pode comprar FlashBuilder, use isso, mas use esse backend Spring + GraniteDS ou BlazeDs. Se você não pode comprar o FlashBuilder, não perca tempo.
  • Vaadin é ótimo !. O processo de desenvolvimento é mais simples do que o Flex, mas você pode criar um aplicativo rico facilmente sem confusão de HTML. Você não vai escrever uma única linha JS. Você só precisa de algum CSS (no Flex, você também precisa). Portanto, se a interface do seu aplicativo vai se comportar como um aplicativo de desktop e você não pode (ou não quer) usar o Flex - use o Vaadin. Aviso! Vaadin tem uma grande sobrecarga de JS para navegador.
  • Se você criar um aplicativo semelhante ao de um site da Web mais simples, use JSF2.0 (com back-end spring como acima). Você precisará lutar com HTML (eu odeio) e criar uma interface rica será mais difícil do que Vaadin (especialmente layouts). Você obterá um HTML leve para navegadores / computadores mais lentos. Gosto do PrimeFaces - é fácil e bem documentado. O segundo lugar é IceFaces
  • Se você criar um site (NÃO um aplicativo da web) onde precisa dar vida ao HTML (em vez de criar um aplicativo corporativo que se encaixe no navegador), use Wicket (se preferir baseado em componente, atitude pull) ou SpringMVC (se preferir baseado em modelo , empurre a atitude) ou apenas use o Play! estrutura. Lembre-se de que criar componentes ricos em dados será muito mais difícil, mas você terá controle sobre cada tag de html (seu HTML / designer gráfico vai adorar)

21
Não vejo como sua resposta se relaciona com a pergunta ...
Pere Villega

1
-1 Parece muito impróprio aceitar esta resposta, uma vez que nem mesmo menciona Java EE 6. Além disso, não aborda nenhum dos pontos levantados no bem pensado @Pascal Thievent (e muito mais bem votado) responda.
user359996

1
Na verdade, a pergunta não é mais válida. O JEE 6 agora está muito maduro, não foi em março de 2010 quando a pergunta foi feita.
Piotr Gwiazda

@PiotrGwiazda de que forma o JEE 6 mudou desde então? As pessoas tinham mais medo dele naquela época, mas era basicamente o mesmo JEE 6.
ymajoros

1
Eu quis dizer que as implementações JEE6 estão mais maduras e disponíveis. O JBoss 7 agora está estável e há mais implementações disponíveis. A comunidade também é maior agora. Mais ferramentas e libs agora suportam JEE 6 stack.
Piotr Gwiazda

8

Leia Future of Enterprise Java de Adam Bien ... Is Clear (Java EE com / sem Spring e vice-versa) , incluindo comentários para obter os dois lados da moeda. Vou escolher o Spring por vários motivos e o seguinte é um deles (reproduzindo um dos comentários da postagem)

'Não tenho certeza de qual servidor Java EE 6 você está falando. Existem certificados Glassfish e TMAX JEUS. Vai demorar um pouco (leia-se: anos) até que as versões compatíveis com Java EE 6 do WebSphere, WebLogic, JBoss etc. estejam em produção e possam ser usadas para aplicativos reais. Spring 3 só precisa de Java 1.5 e J2EE 1.4, portanto pode ser usado prontamente em quase todos os ambientes '


6
Estamos quase exatamente um ano depois e o JBoss AS 6, que oferece suporte a Java EE 6, está sendo usado na produção.
Arjan Tijms

8

Minha opinião é baseada em algo não mencionado por outros, ou seja, que o código no meu trabalho tende a durar décadas (literalmente) e, portanto, a manutenção é muito importante para nós. Manutenção do nosso próprio código e das bibliotecas que usamos. Nós controlamos nosso próprio código, mas é do nosso interesse que as bibliotecas que usamos sejam mantidas por terceiros nas décadas acima mencionadas ou mais.

Para encurtar a história, concluí que a melhor maneira de conseguir isso é usando implementações de software livre das especificações da Sun até o JVM bruto.

Das implementações de código aberto, o Apache Jakarta provou manter suas bibliotecas e, recentemente, a Sun fez muito trabalho na produção de implementações de alta qualidade para Glassfish v3. Em qualquer caso, também temos o código-fonte de todos os módulos, portanto, se tudo o mais falhar, podemos mantê-los nós mesmos.

As especificações da Sun são geralmente muito restritas, o que significa que as implementações em conformidade com as especificações podem ser trocadas facilmente. Basta dar uma olhada nos contêineres de servlet.

Nesse caso específico, eu sugeriria dar uma olhada no JavaServer Faces simplesmente porque ele faz parte do Java EE 6, o que significa que estará disponível e será mantido por muito, muito tempo. Em seguida, optamos por aumentar com MyFaces Tomahawk, pois oferece algumas adições úteis, e é um projeto jakarta.

Não há nada de errado com o JBoss Seam ou outros. Acontece que o foco deles é menos na questão da manutenção que é tão importante para nós.


Descobriu-se que Java ServerFaces 2 em Java EE 6 poderia fazer por conta própria o que precisávamos do Tomahawk com JSF 1. É um framework bastante capaz (mas um pouco pesado em XML)
Thorbjørn Ravn Andersen

Muito bem, infelizmente as pessoas tendem a esquecer que o software é feito para durar décadas e que o suporte de longo prazo é uma chave crucial.
timmz

6

Posso ver usando o Spring se você já o tem, mas para o novo projeto, qual é o ponto? Eu iria diretamente com o Java EE 6 (ejb3, jsf2.0, etc.)

Se o cliente está bem com o Flex, vá em frente. Use BlazeDS ou similar - sem mvc. Você pode gastar mais tempo nessa parte (trocando dados entre o servidor e o cliente), mas tem controle total de ambos os lados.

Não use Vaadin, a menos que queira encerrar seu navegador. Além disso, você gasta mais tempo contornando o código quando suas páginas se tornam mais complexas. Além disso, sua mentalidade precisará ser completamente mudada e tudo o que você sabe sobre o desenvolvimento de front-end padrão será desperdiçado. O argumento de que você não precisa usar HTML ou JS não faz muito sentido. Você ainda precisa saber disso, mesmo que não o use. Ele renderiza para HTML e JS eventualmente. Em seguida, tente depurá-lo - certifique-se de ter alguns dias para coisas simples. Além disso, não consigo imaginar um desenvolvedor web que não conheça html / js.

Só não entendo por que as pessoas estão tentando todas essas abstrações em vez de usar o Java EE diretamente.


5

Por que ainda há rumores sobre o EJB ser peso pesado em 2010? Parece que as pessoas não estão sendo atualizadas nas tecnologias Java EE. Apenas experimente, você ficará agradavelmente surpreso como as coisas são simplificadas no Java EE 6.


4

A resposta às suas perguntas depende dos requisitos do seu projeto. Se você não precisar dos recursos Java EE, como filas de mensagens, transações globais gerenciadas por contêiner, etc., escolha tomcat + spring.

Também por experiência, descobri que os projetos que requerem muita integração de serviço da Web, agendamento e filas de mensagens são mais bem executados usando parte da pilha Java EE. A boa coisa é que usando o Spring você ainda pode integrar com módulos Java EE rodando em um servidor de aplicativos.

O Java EE 6 é muito diferente das versões anteriores e realmente torna tudo muito mais fácil. O Java EE 6 combina as melhores idéias da comunidade Java diversa - por exemplo, Rod Johnson do framework Spring esteve ativamente envolvido na criação do JSR de injeção de dependência no Java EE 6. Um benefício de usar o Java EE 6 é que você está codificando de acordo com um padrão, que pode ser importante em algumas organizações para suporte de fornecedores etc.

GlassFish v3 suporta Java EE 6 e é bastante leve e inicializa muito rápido. Tenho usado o glassfish v3 para meus desenvolvimentos e é realmente fácil de configurar. Ele vem com um console de administração muito amigável que permite que você administre seu servidor graficamente.

Se você estiver usando GlassfishV3 e JSF 2, poderá aproveitar os recursos do CDI do Java EE 6, que permite criar conversas facilmente (por exemplo, páginas do tipo assistente) no JSF.

Dito isso, usar o Java EE 6 também requer que você aprenda uma nova API. Dependendo do período de tempo disponível, pode não ser a melhor escolha para você. O Tomcat existe há muito tempo, e a combinação tomcat + spring foi adotada por muitos projetos da web, o que significa que existem muitos fóruns / documentação disponíveis.


Não concordo com a sua primeira frase, a escolha não é sobre usar JMS ou não. E eu não acho que JSR-330 seja tão importante no Java EE 6 (está mais lá por razões políticas), a parte importante é JSR-299 (CDI). Pelo menos, esta é minha opinião.
Pascal Thivent

Concordo que havia algumas políticas envolvendo JSR330 - no entanto, é muito importante, pois fornece uma base comum para injeção de dependência em Java (SE ou EE) em vez de tornar o DI uma tecnologia apenas para JEE. Além disso, é suportado pelo framework Spring e Google Guice, o que significa que tornará o código Spring / Guice fácil de portar para JEE6 ou vice-versa. JSR299 também foi projetado para estender os recursos do JSR330. Você está correto ao dizer que, para aplicativos da web em JEE6, JSR299 é absolutamente crucial. Graças a esses dois JSRs, JEE6 e Spring têm modelos de programação muito semelhantes. Obrigado pelo seu comentário!
Raz

3

Trabalhei tanto no Spring quanto no Java EE 6. O que posso dizer por experiência própria é que se você estiver optando pelo JSP antigo ou pelo Flex proprietário, estará seguro se ficar com o Spring.

Mas se você deseja avançar com o JSF, é hora de mudar para o Java EE 6. Com o Java EE 6, você está mudando para Facelets e bibliotecas de script padronizadas e bibliotecas de componentes. Não há mais incompatibilidades de script e matrizes de biblioteca de componentes.

Em relação ao Spring MVC, é bom, desde que seu projeto não cresça muito. Se for um aplicativo corporativo enorme, use o Java EE 6. Porque essa é a única maneira de manter suas próprias bibliotecas de componentes e pacotes de recursos de maneira ordenada.


1
Obrigado por seu comentário. Minha escolha foi Spring + Vaadin.
Piotr Gwiazda

3

Se você precisa da pilha completa do Java EE, eu recomendo o GlassFish 3.1. Ele inicia muito rapidamente em comparação com outros contêineres Java EE que implementam alguma parte ou todo o Java EE 6 (JBoss 6, WebLogic 10.3.4), a reimplantação leva segundos e quase tudo pode ser feito por convenção sobre configuração, é muito amigável.

Se você quiser algo "leve", você pode personalizar um Apache Tomcat 7.x com os recursos desejados. Usei muito com as seguintes bibliotecas: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - apenas transações locais de recursos JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Sendo um desenvolvedor Java EE nos últimos 10 anos (eu sofro com EJB, JSF e tecnologias web), Java EE 6 é muito fácil, bem acoplado e o hardware atual funciona bem, então motivos originais que motivaram o Spring não são mais válidos.


1
Eu gosto da sua resposta. Muito razoável. Quando postei a pergunta, o JEE6 era muito jovem e o Tomcat 7 ainda não havia terminado. "As razões originais que motivaram o Spring não são mais válidas" - é verdade, mas JEE6 com CDI precisa de algum tempo para ser analisado. Por exemplo: o monitoramento Javamelody está disponível para Spring e Guice (não consigo me imaginar gastando em aplicativos sem ele). EHcache está disponível para Spring (quero dizer resultados de métodos de cache). Muitas coisas como a programação de aspectos ainda são mais fáceis no Spring, porque muitas bibliotecas e estruturas de terceiros se integram facilmente com o Spring, mas ainda não com o JEE6.
Piotr Gwiazda

1

Eu ainda prefiro a primavera.

E eu deixaria de lado o JSF. Acho que é uma tecnologia morta. Spring MVC seria uma alternativa melhor. Flex também. Pense primeiro nos termos do contrato de serviços XML e você pode separar o back-end da UI completamente.


1
Criei alguns aplicativos com Java + Flex e PHP + Flex e concordo que é a melhor solução para interfaces ricas. Mas neste aplicativo eu não posso usar Flex :( Eu preciso de alguma interface de alto nível, então Spring MVC não é uma solução. Eu quero pensar em tabela de dados classificável tanto quanto <tr> <td> em um loop.
Piotr Gwiazda,

1
@duffymo - Posso argumentar se o flex é uma boa escolha. JSF definitivamente não está morto, especialmente com bibliotecas como richfaces, primefaces, icefaces, etc. por aí.
Bozho

1
No IceFaces eu crio menus, árvores, datagrids, uso ações, eventos e não penso se a página recarrega ou é uma solicitação ajax. Um datagrid classificável ou árvore carregada com Ajax é um componente embutido. No Spring MVC eu opero em HTML - tabelas, listas etc. Eu preciso usar algum framework javascript de terceiros e criar mágica AJAX manualmente. Eu gostaria de fazer isso no Flex, mas é uma decisão política / comercial - não minha.
Piotr Gwiazda

1
Meus dois projetos JSF atuais definitivamente não estão mortos;) E estou muito mais satisfeito com a maneira JSF de construir RIA ("rico" em "richfaces" é para isso), do que usar Flex. Um vai até abrir o capital na próxima semana.
Bozho

2
Eu realmente gostaria de saber por que você ainda prefere o Spring, Java EE 6 é muito bom. Você não acha que rodar em uma plataforma aberta é importante para o futuro do Java?
Pascal Thivent

0

Eu recomendaria Spring + Tomcat, a menos que você possa esperar o tempo para o glassfish v3 e o Weld se tornarem mais maduros. Atualmente, existem alguns problemas com o consumo de memória / carga da CPU ao executar o glassfish com aplicativos habilitados para CDI.


0

Não li tudo, mas apenas para dizer que agora você pode usar EJB3 dentro de uma guerra no Java EE 6 para que você possa usar EJB3 no Tomcat (eu acho).


Sim, você pode empacotar EJBs em um WAR no Java EE 6, mas isso não significa que você pode implantar esse WAR no Tomcat. Você precisa de um contêiner que implemente o Perfil da Web e o Tomcat não e, na verdade, não há nenhum plano na comunidade do Tomcat para implementá-lo (consulte old.nabble.com/Java-EE-6-Web-Profile-td27715793.html ). Mas há GlassFish v3 Web Profile, haverá resina ...
Pascal Thivent

2
atualização: dê uma olhada em TomEE + projeto tomee.apache.org/apache-tomee.html
gpilotino

-3

Recomendei a você o Tomcat com Spring porque:

  1. Spring pode criar beans de apoio para JSP
  2. Você usará Spring para persistir o objeto por meio de JPA

É uma boa escolha escolher o Tomcat porque você não precisa de nenhum processamento pesado


1
"Processamento pesado"? Você poderia elaborar? Estou curioso.
Pascal Thivent
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.