[quote=Frentic]Graças ao bom deus eu nao uso EJB.
EJB is dead for me :)[/quote]
Uma pena você encarar EJB3 com a mesma raiva que encara as outras versões…
vai descobrir que uma porrada de frameworks que vc usa poderia estar deixando de lado se adotasse a versão 3.0…
All in one 
Se ele usasse EJB ele também poderia continuar perdendo um tempão esperando o Glassfish subir todos os EJBs 
[quote=Rubem Azenha][quote=chun]
Uma pena você encarar EJB3 com a mesma raiva que encara as outras versões…
vai descobrir que uma porrada de frameworks que vc usa poderia estar deixando de lado se adotasse a versão 3.0…
All in one
[/quote]
Se ele usasse EJB ele também poderia continuar perdendo um tempão esperando o Glassfish subir todos os EJBs :P[/quote]
e o tempo de carga de um EJB ( que sinceramente eh bem rapido , aqui eh ms…) é fator para trocar all in one por um milhao de frameworks adicionais ? com 300 configuracoes a toa ? me desculpe… mas desculpinha mais boba hein ?
Tá, quantos frameworks você jogou no lixo por usar EJB3?
Não é jogar no lixo , é abstratir por interfaces padrão de trabalho…
Vamos começar a enumerar…
Acho que isso já dá uma boa curva de aprendizado…
Fora os beneficios que o container tem como JMS, Controle de transacoes unificado , load balance , entre outros 
Para uma equipe grande isso é MUITO legal… todos trabalharem da mesma forma sem “piracoes a parte”
Vamos lá:
Desde quando EJB substitui Struts?
E quanto ao Hiberante, usa JPA, que é basicamente um clone do Hibernate, a complexidade é a mesma.
Quanto ao ACEGI eu até entendo que é um framework a menos, mas o que eu mais vejo é o pessoal fazendo a segurança na camada web. Não acho que o ACEGI requer tanta configuração assim, é quase como configurar junto com o Spring mesmo.
“Controle de transacoes unificado” -> O Spring tem isso tão simples quanto EJB.
“load balance” -> Com EJB você tem load-balance da camada de negócios mas na imensa maioria dos casos basta fazer um load balance da camada web. Acho que fazer load balance da camada de negócios é essencial em alguns casos, como processamentos assincronos pesados, batches, etc. Fazer load balance da camada de negócio para coisas simples como uma página de busca simples não vale a pena ao meu ver.
[quote=Rubem Azenha]Vamos lá:
Desde quando EJB substitui Struts?
E quanto ao Hiberante, usa JPA, que é basicamente um clone do Hibernate, a complexidade é a mesma.
Quanto ao ACEGI eu até entendo que é um framework a menos, mas o que eu mais vejo é o pessoal fazendo a segurança na camada web. Não acho que o ACEGI requer tanta configuração assim, é quase como configurar junto com o Spring mesmo.
“Controle de transacoes unificado” -> O Spring tem isso tão simples quanto EJB.
“load balance” -> Com EJB você tem load-balance da camada de negócios mas na imensa maioria dos casos basta fazer um load balance da camada web. Acho que fazer load balance da camada de negócios é essencial em alguns casos, como processamentos assincronos pesados, batches, etc. Fazer load balance da camada de negócio para coisas simples como uma página de busca simples não vale a pena ao meu ver.[/quote]
Vamos lá por topico… EJB dentro de java EE substitui o strus com JSF…
Ninguem usa EJB sem se benificiar do Java EE… seria besteira…
JPA asbtrai hibernate… nao importa o que uso para persistencia… importa aprender JPA… menos uns 415 frameworks ORM… quem trabalha com JPA trabalha com qualquer ORM que o implemente… ( e isso quer dizer muita coisa )
512312314 XMl’s ? Por favor… EJB eh um @transaction no metodo… ou no bean… admita… pegar um IDE que suporte isso é bem mais facil que sair corrende procurando plugins atualizados…
Quanto ao load balance , voce falou falou e falou… em EJB isso é transparente … tanto na web quanto na camada de negocios… convido voce a testar o clustering support do Glassfish. Valer a pena depende de “quantos clicks” voce demora para balancear sua regra de negocio… quando se trata de mensagens assincronas isso é bastante util…
Opa, pera lá. A discussão é sobre EJB e não sobre Java EE. (EJB 3: Dead or Alive? e não Java EE puro e simples dead or alive).
E, sinceramente, muita gente (eu incluso) vai preferir não usar JSF.
Aprender JPA = Aprender Hibernate. Quem conhece um mínimo de Hibernate sabe que JPA é uma cópia de um subset do Hibernate. As APIs são muito parecidas. Logo a complexidade é a mesma.
E não me venha com essa de que basta aprender JPA que você trabalha com qualquer ORM, basta ver que existem diferenças significativas entre as implementações de JPA.
No Spring também
Cara, que que load balance na web tem haver com EJB? Load balance pra web é transparente com Spring.
Sinceramente, cluster, load-balance, fail-on-over, escalabilidade, etc são coisas tão sérias e complexas que a coisa que eu menos me preocupo é quantos cliques eu vou demorar para balancear a minha regra de negócio.
Concordo que no quesito de processamento assincrono EJB é imbatível. JMS+MDB rules
Respondendo:
EJB sem JavaEE não tem muito sentido… perde-se muito… quanto ao JSF como te disse SUBSTITUI… agora se vc quer ou não eh opção sua.
Aprender JPA != Aprender Hibernate… Hibernate faz muita coisa da maneira dele… e mais mais que JPA… não é igual… JPA por exemplo nao tem criteria… a complexidade é maior. Voce poderia me citar qual a diferenca entre uma implesmentacao de JPA e outra ? se implementa JPA tem que seguir diversos padroes… voce tem um exemplo concreto disso ?
Spring com annotations ? só se for na super mega versao nova… ou com mais um framework do urubatan… mais um hein ? hehehe
Brinque com o Glassfish e vai perceber o que load balance na web tem a ver com EJB As vezes voce precisa balancear a carga da regra de negocio e com glassfish isso é simples.
Vou entrar nesta discussão tb.
[quote=Rubem Azenha][quote=chun]
Vamos lá por topico… EJB dentro de java EE substitui o strus com JSF…
Ninguem usa EJB sem se benificiar do Java EE… seria besteira…
[/quote]
Opa, pera lá. A discussão é sobre EJB e não sobre Java EE. (EJB 3: Dead or Alive? e não Java EE puro e simples dead or alive).
E, sinceramente, muita gente (eu incluso) vai preferir não usar JSF.
[/quote]
concordo com chun, apesar de ter se desviado um pouco do foco de EJB3.
mas pq muita gente vai preferir não usar JSF?
depois que conheci JSF, nunca mais quis voltar para Struts.
Vamos focar em EJB e esquecer o resto.
http://lists.jboss.org/pipermail/hibernate-issues/2007-August/006677.html
Apenas um exemplo.
Não mesmo. Não lembro exatamente em qual versão do Spring veio isso. Acredito que na versão 2. Não estou lembrado, mas faz um tempinho que já tem isso.
Ta, você configura os dois juntos com o mesmo clique, isso não significa que funcionam da mesma forma ou que sem usar EJB\glassfish seja uma coisa do outro mundo.
Alias, estamos discutindo o que aqui, EJB ou Glassfish?
Dificil… um exemplo seria o controle de transacoes é por parte do JTA que é JEE e nao EJB… entre outros…
É um bug cerebral do pessoal do Hibernate, é só seguir JPA e deixar essa “feature” de lado Não entendi sua colocação… ainda se eu seguir JPA posso usar hibernate… do contrario tenho este problema que voce citou.
Tempinho ? Fale com o urubatan… ele sabe bem quanto TEMPINHO a Interface21 levou para “lembrar” que existe annotations…
Nao funcionam da mesma forma… eles “apenas funcionam” , e ae voce configura detalhes do balanceamento mas eh bem DRY e CPE
Glassfish Implementa Jave EE 5 e atualmente é o container mais “amigavel” do mercado OpenSource
[quote=chun]1) Dificil… um exemplo seria o controle de transacoes é por parte do JTA que é JEE e nao EJB… entre outros…
[/quote]
Desisto…
Antes de mais nada eu teria muito cuidado antes de falar que o pessoal do Hibernate tem um bug cerebral
Acho que você não leu o meu link, é um bug report que eu fiz de uma funcionalidade: o uso de Date e Calendar. A JPA do Hibernate não obriga o uso de @Temporal, o Toplink obriga. O ponto é: esse é apenas um exemplo de uma funcionalidade que funciona diferente em duas implementações de JPA, e, sim, existem mais exemplos de incompatibilidades entre as implementações.
Cara, o Spring 2 saiu no final de 2006, vai fazer dois anos
Desisto de novo. Fazer cluster não é só dar uns cliques no console do glassfish e você tem um cluster com load balance e tudo mais. Há muito mais envolvido. Além disso, configurar cluster em outros AS e cluster da camada web sem AS não é complicado também.
Vamos lá denovo hehehe:
Não desista… admita… EJB esta contido em Java EE e não teria nem logica em usar um sem o outro… voce pode até não usar os recursos do container… mesmo assim vai estar usando JavaEE
Segundo a SPEC quem está certo ?
JavaEE 5 é bem mais velho fora que é uma spec e não um framework.
Não acho… eh isso que voce não entende… eu compreendi a sua parte… mas em glassfish fazer um setup INICIAL para isso é SIMPLES… fazer tunning em cima disso é outros 500 , separar quais nós vão cuidar de quais servicços é outros 500… agora, se voce precisar fazer isso, vai perceber que tmb não é um bicho de 7 cabeças…
A questão não é quem esta certo ou quem esta errado, a questão é que não basta adicionar JPA.JAR no lib do projeto e sair usando JPA a torto e a direito sem entender as particularidades implementação. Então essa de que é usar JPA é um framework a menos para entender cai por agua abaixo.
Isso por que eu nem mencionei a questão do second-level cache que não é coberta pela especificação!
Java EE 5 é ‘bem’ mais velho, ok. O ponto não é esse
O ponto é que eu não preciso de um AS que leva pelo menos 10 vezes mais para carregar para controlar transação com anotação
Caramba, a discussão era sobre uso de N frameworks X EJB, pare de ficar falando que o glassfish é isso ou aquilo. Ta parecendo eu falando do Mentawai po 
EJB3 ++
O legal é que os dois brigam, não chegam a lugar nenhum e todo mundo se beneficia da diversidade que temos.
Embora eu, pessoalmente, prefiro usar um mínimo de frameworks e aderir à especificação.
[quote=danieldestro]O legal é que os dois brigam, não chegam a lugar nenhum e todo mundo se beneficia da diversidade que temos.
Embora eu, pessoalmente, prefiro usar um mínimo de frameworks e aderir à especificação.[/quote]
Eu já prefiro os frameworks hehehe
E os dois não estão brigando, só discutindo. O chun é evangelista de carteirinha mesmo, então é facinho de rolar uma discussão longa com ele defendendo o glassfish, ejb e o netbeans como se fossem as últimas ferramentas/frameworks/specs do mundo
Olá
[quote=leandrokjava]mas pq muita gente vai preferir não usar JSF?
depois que conheci JSF, nunca mais quis voltar para Struts.
[/quote]
Quando conheci JSF (na versão 1.0), fiquei com a impressão que da Sun dificilmente sairá algo que preste em termos de desenvolvimento web. Será que um dos motivos é que o criador do Struts 1.x trabalha lá?
[]s
Luca
Eu uso EJB 3 e to achando bom, bem facim