Spring Framework 3.0 RC1 released

This message was edited 1 time. Last update was at 05/10/2009 08:48:45

javaranch, eu não fiz uma afirmação, fiz uma pergunta.

Alessandro Lazarotti wrote:

legionarioba wrote:
Você tem um facade, que é seu EJB, lá você anota ele (@EJB). Simples, ok...mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco...

Não defendendo ninguém, mas pq usar um EJB como "DAO" (suponhando que fosse necessário realmente um DAO em seu projeto) atras de uma Façade seria um equívoco? Não consigo compreender este tipo de afirmação solta fora de algum contexto. Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?

Não é questão de usar EJB com Dao..Poderia ser DAO, BO, qualquer camada em sua divisão arquitetural...a afirmação apenas foi pra denotar que qualquer injeção de alguma classe colaborativa que você venha a ter no seu EJB, usando apenas EJB, você precisaria da anotação @EJB...O que questionei foi: transformar uma classe colaborativa qualquer em EJB para usar a injeção de dependência. A questão não é só o custo de um Stateless, mas o fato de deixar uma brecha para expôr uma classe colaborativa(BO, DAO, Repository o que for), e que esta não deveria ser acessível remotamente, ter por exemplo um Ejb de fachada, acessando um EJB de negócio, que acessa um EJB de acesso a dados, algo desse tipo... Este é o equívoco...
Acredito que o custo de manter o cache de uma instância num microcontainer seja menos custoso que um Stateless em um server JEE(mas não tenho benchmarking pra tal)...

Olha...
nego fala mal do EJB... que é complicado , que é amarrado...

Quero que essa mesma pessoa utilize o Spring-WS uma vez na vida...

Ai sim ela vai descobrir o que é complicar o incomplicavel !

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Bom, o java 1.4 foi abandonado ha anos e ainda é usado por ai. O java 5 irá perder suporte (será descontinuado) a partir de 29 de outubro deste ano (sim, no final do mês) Portanto subir para 1.5 é meio atrasado. Deveria ter subido direto para 1.6 que ainda vai durar mais 2 anos por ai. Afinal sintáticamente não ha grande diferença mudar de 1.4 para 1.5 ou para 1.6 e os recursos do 1.6 são bem melhores (porque a API é maior).

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Alessandro Lazarotti wrote: Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?

Sim é. Pela simples razão que todos os EJB são trasnaction aware e context awere. Em Spring eles não são nenhum dos dois. Vc precisa configurar que quiser funcionalidades equivalentes. Um pojo no spring é mais leve.

Aos amantes de POJO no Spring:

http://www.adam-bien.com/roller/abien/entry/is_it_worth_using_pojos

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

legionarioba wrote:

Alessandro Lazarotti wrote:

legionarioba wrote:
Você tem um facade, que é seu EJB, lá você anota ele (@EJB). Simples, ok...mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco...

Não defendendo ninguém, mas pq usar um EJB como "DAO" (suponhando que fosse necessário realmente um DAO em seu projeto) atras de uma Façade seria um equívoco? Não consigo compreender este tipo de afirmação solta fora de algum contexto. Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?

Não é questão de usar EJB com Dao..Poderia ser DAO, BO, qualquer camada em sua divisão arquitetural...a afirmação apenas foi pra denotar que qualquer injeção de alguma classe colaborativa que você venha a ter no seu EJB, usando apenas EJB, você precisaria da anotação @EJB...O que questionei foi: transformar uma classe colaborativa qualquer em EJB para usar a injeção de dependência. A questão não é só o custo de um Stateless, mas o fato de deixar uma brecha para expôr uma classe colaborativa(BO, DAO, Repository o que for), e que esta não deveria ser acessível remotamente, ter por exemplo um Ejb de fachada, acessando um EJB de negócio, que acessa um EJB de acesso a dados, algo desse tipo... Este é o equívoco...
Acredito que o custo de manter o cache de uma instância num microcontainer seja menos custoso que um Stateless em um server JEE(mas não tenho benchmarking pra tal)...

Mas legionarioba], não é pq é EJB que precisa ser "remote", ele pode ser "local". Tbm não é pq vc usa EJB que você não pode utilizar qualquer framework de DI para injeção de classes utilitárias.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

sergiotaborda wrote:

Alessandro Lazarotti wrote: Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?

Sim é. Pela simples razão que todos os EJB são trasnaction aware e context awere. Em Spring eles não são nenhum dos dois. Vc precisa configurar que quiser funcionalidades equivalentes. Um pojo no spring é mais leve.

Você pode desarmar os dois lados Sergio. Um EJB só vai ter conhecimento transacional se for CMT, assim como um Spring Bean só vai ser transacional se assim declarado como tal.

Outro ponto é que os serviços relacionados a seus estados ou gerencia de contextos não o tornam mais pesados, muito pelo contrário. Um pool de 10 Stateless gerenciados pode atender mais clientes em solicitações concorrentes do que um bean singleton do Spring, justamente pq é um pool gerenciado. Neste caso um bean, inchado, pode ser mais pesado para responder aos processamentos do que um pool.

chun wrote:Olha...
nego fala mal do EJB... que é complicado , que é amarrado...

Quero que essa mesma pessoa utilize o Spring-WS uma vez na vida...

Ai sim ela vai descobrir o que é complicar o incomplicavel !

chun, só uma pergunta, tu sabes a diferença entre contract-first e contract-last web-services?

JAX-WS e Spring Web-services, apesar de ambos trabalharem com web-services (duh!) o objetivo final é totalmente diferente. Eu mesmo já usei ambos e, cada um é feito para uma situação diferente, não existe melhor ou pior.

Esses teus chiliques quando vê a palavra Spring e a palavra JBoss aqui no GUJ enchem o saco, de boa cara. Nada contra você, mas é que TODO, mas TODO tópico que falam algo que possa "abalar" o EJB e o Glassfish tu já chega na voadora, trollando geral.

Eu só vejo você nesse tipo de tópico, só.

Leozin wrote:

chun wrote:Olha...
nego fala mal do EJB... que é complicado , que é amarrado...

Quero que essa mesma pessoa utilize o Spring-WS uma vez na vida...

Ai sim ela vai descobrir o que é complicar o incomplicavel !

chun, só uma pergunta, tu sabes a diferença entre contract-first e contract-last web-services?

Sim , porem acho uma abordagem dispensavel em 90% dos casos , e outros 10% é a melhor abordagem... o Srping-WS para *variar* acha o contrario...

Leozin wrote:
JAX-WS e Spring Web-services, apesar de ambos trabalharem com web-services (duh!) o objetivo final é totalmente diferente. Eu mesmo já usei ambos e, cada um é feito para uma situação diferente, não existe melhor ou pior.

Descordo , MESMO sendo um webservice contract-first , poderia-se ter feito algo bem mais intuitivo e produtivo.

Leozin wrote:
Esses teus chiliques quando vê a palavra Spring e a palavra JBoss aqui no GUJ enchem o saco, de boa cara. Nada contra você, mas é que TODO, mas TODO tópico que falam algo que possa "abalar" o EJB e o Glassfish tu já chega na voadora, trollando geral.

Chiliques ? Isto tem um nome , se chama OPINIAO... agora se vc expressa sua opiniao com CHILIQUES , ai eh uma decisao sua

Leia o rodape do minha mensagem

Quanto a voadoras , não sao voadoras... se chama ARGUMENTOS , se voce expressa seus argumentos dando VOADORAS nos outros , ai eh OUTRO problema seu

Leia o rodape da minha mensagem

Leozin wrote:
Eu só vejo você nesse tipo de tópico, só.

Que bom

assim vc tem o que falar nos topicos

chun wrote:Aos amantes de POJO no Spring:

http://www.adam-bien.com/roller/abien/entry/is_it_worth_using_pojos

É que o cara usou o maravilhoso ultra-power mega glassfish plus. Se tivesse usado JBoss teria sido bem mais lento.*

*Sarcasmo.

Rubem Azenha wrote:

chun wrote:Aos amantes de POJO no Spring:

http://www.adam-bien.com/roller/abien/entry/is_it_worth_using_pojos

É que o cara usou o maravilhoso ultra-power mega glassfish plus. Se tivesse usado JBoss teria sido bem mais lento.*

*Sarcasmo.

Na realidade ele poderia ter utilizado qualquer container , mas neste caso foi o GlassFish...
Mas se voce realmente testou no JBoss e ficou mais lento , reporte aqui

Agora , se voce nao testou em nenhum deles e apenas fez esse comentario para parecer o "ENGRAÇADÃO DA ESTRELA®" então essa vai para voce fiar feliz hoje:

"hanhahahahahahahaAHAHAhAhAhAhAhAHAHAHAHA"

Alessandro Lazarotti wrote:

legionarioba wrote:

Alessandro Lazarotti wrote:

legionarioba wrote:
Você tem um facade, que é seu EJB, lá você anota ele (@EJB). Simples, ok...mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco...

Não defendendo ninguém, mas pq usar um EJB como "DAO" (suponhando que fosse necessário realmente um DAO em seu projeto) atras de uma Façade seria um equívoco? Não consigo compreender este tipo de afirmação solta fora de algum contexto. Por acaso você acha que um Stateless é mais caro para um servidor JavaEE do que um POJO seria para um microcontainer como o Spring?

Não é questão de usar EJB com Dao..Poderia ser DAO, BO, qualquer camada em sua divisão arquitetural...a afirmação apenas foi pra denotar que qualquer injeção de alguma classe colaborativa que você venha a ter no seu EJB, usando apenas EJB, você precisaria da anotação @EJB...O que questionei foi: transformar uma classe colaborativa qualquer em EJB para usar a injeção de dependência. A questão não é só o custo de um Stateless, mas o fato de deixar uma brecha para expôr uma classe colaborativa(BO, DAO, Repository o que for), e que esta não deveria ser acessível remotamente, ter por exemplo um Ejb de fachada, acessando um EJB de negócio, que acessa um EJB de acesso a dados, algo desse tipo... Este é o equívoco...
Acredito que o custo de manter o cache de uma instância num microcontainer seja menos custoso que um Stateless em um server JEE(mas não tenho benchmarking pra tal)...

Mas legionarioba], não é pq é EJB que precisa ser "remote", ele pode ser "local". Tbm não é pq vc usa EJB que você não pode utilizar qualquer framework de DI para injeção de classes utilitárias.

Só quis dizer que injeção de dependência com "EJB puro" só funciona com quem está anotado com @EJB (não entrei no mérito de ser local ou remote). Ainda sim, conceitualmente uma camada de acesso a dados não é um EJB(ainda que eu possa minimizar isso utilizando como local)... E claro, além do Spring poderia ser qualquer outro frame de DI...(mas já que o tópico é sobre Spring..

)

Meu único pensamento é: não fazer de uma classe qualquer um EJB(ainda que local), pra usar DI...

JavaTeenager Membro desde: 02/10/2007 10:56:53 Mensagens: 162 Offline

Voltando um pouco ao tópico.
O 2.5 vai ser descontinuado?
Alguém aqui já colocou algo em produção com o 3.0? Visto que ele já está a um bom tempo em beta?
Será que da RC para versão final vai demorar muito?

Agora fugindo um pouco do tópico. Como anda a implementação da JPA 2.0 para o Hibernate? A versão 3.5 que vocês estão falando já implementa? Não encontrei o changelog.

Notícias, artigos e o maior fórum brasileiro sobre Java