Arquivo Discussoes de Programacao e Tecnologia 
Foi lançado recentemente o primeiro Release Candidade do Spring Framework 3.0.
Entre os destaques estão:
Fonte e mais detalhes em:
Taí uma grande notícia!
Abraços.
Já estava na hora de migrar para Java 5. A propósito será que vai demorar muito para o jakarta-commons ir para Java 5?
Agora, dentre uma série expression-languages, havia mesmo necessidade de mais uma?
Alguém tem informação se é suportável aplicação de Spring on Rails ?
Thanks !!!
heheh
Falta ainda o Hibernate.
Com o EJB 3 o Spring perdeu um pouco do “glamour”, mas continua sendo uma ótima ferramenta.
Na verdade não vejo os dois como concorrentes. Se você quer algo simples vale a pena spring. Nem sempre você pode contar com um appserver. Já se eu puder ter um Weblogic/Glassfish, por exemplo, eu usaria sem duvidas EJB, afinal, para que vou ter um appserver para não usar tudo que a spec me oferece. Mas quando vocẽ não pode ter isso, o Spring é o the best.
Saiu um preview do Hib3.5. Segundo lí a idéia é unificar o hibernate-core, -annotations e -entity-manager. Creio que assim ele ficaria full Java5.
Abraços
Já estava na hora de migrar para Java 5. A propósito será que vai demorar muito para o jakarta-commons ir para Java 5?
O impacto disso se dará nas aplicações que usam Java 1.4.
O mais indicado seria criar uma versão para Java 5. Mas vem outra questão: vale a pena manter duas versões?
heheh
Falta ainda o Hibernate.
Com o EJB 3 o Spring perdeu um pouco do “glamour”, mas continua sendo uma ótima ferramenta.
Na verdade não vejo os dois como concorrentes. Se você quer algo simples vale a pena spring. Nem sempre você pode contar com um appserver. Já se eu puder ter um Weblogic/Glassfish, por exemplo, eu usaria sem duvidas EJB, afinal, para que vou ter um appserver para não usar tudo que a spec me oferece. Mas quando vocẽ não pode ter isso, o Spring é o the best.
Saiu um preview do Hib3.5. Segundo lí a idéia é unificar o hibernate-core, -annotations e -entity-manager. Creio que assim ele ficaria full Java5.
Abraços
Mais simples ?
Tem coisa mais simples que um @Stateless ? um @EJB ?
Já estava na hora de migrar para Java 5. A propósito será que vai demorar muito para o jakarta-commons ir para Java 5?Agora, dentre uma série expression-languages, havia mesmo necessidade de mais uma?
O pessoal da SpringSource nao tah nem ai para o mercado…
Eles já aprontaram destas mais de uma vez…
Simplesmente ignoraram o spring-annotaions do urubatan e foram lá fazendo anotacoes ao “estilo deles”…
Nao eh novidade criar mais uma …
Aff… o wicket já foi para o 1.5, spring tá indo e hibernate também? Pqp, o generics do java 5 é um porre. Sinceramente, estas evoluções estão me “brochando”.
Aff… o wicket já foi para o 1.5, spring tá indo e hibernate também? Pqp, o generics do java 5 é um porre. Sinceramente, estas evoluções estão me “brochando”.
Aff… o wicket já foi para o 1.5, spring tá indo e hibernate também? Pqp, o generics do java 5 é um porre. Sinceramente, estas evoluções estão me “brochando”.
:arrow: Acho que essa leitura é essencial
não, não é!
Chun, mais simples no sentido de aplicação simples.
Já estava na hora de migrar para Java 5. A propósito será que vai demorar muito para o jakarta-commons ir para Java 5?Agora, dentre uma série expression-languages, havia mesmo necessidade de mais uma?
O pessoal da SpringSource nao tah nem ai para o mercado…
Eles já aprontaram destas mais de uma vez…Simplesmente ignoraram o spring-annotaions do urubatan e foram lá fazendo anotacoes ao “estilo deles”…
Nao eh novidade criar mais uma …
aproveitando, alguém já conferiu a 3ª edição do livro “spring in action” ? poderia comentar sobre o que achou!
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…
Simples, ok…mas ai você quer injetar um dao , vai querer usar um @EJB tb? Simples, mas seria um equívoco…Pra que usar dao?
Eu peguei o Meap esses dias na promoção de 50%. Infelizmente nunca achei o in action do Spring melhor que o Pro Spring da Apress. Quero mesmo é esse:
http://www.apress.com/book/view/9781430218456
O da versão 2.5 tava show.
Você não vai implementar lógica de negócio, acesso a dados, tudo na sua implementação do EJB vai? :shock:
Seu dominio é um DAO que se projeta desenhado um pedaços de classes que são refletidas para objetos que persistem dinamicamente na sua camada de dados, via JPA, Hibernate, ou qualquer outro framework que atue nesse paradigma.
Hmmmmmmm… e não é que eles aderiram aos padrões!!!
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?
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?
Você não vai implementar lógica de negócio, acesso a dados, tudo na sua implementação do EJB vai? :shock:
Você está usando JPA e está implementando os DAOs?
Seu dominio é um DAO que se projeta desenhado um pedaços de classes que são refletidas para objetos que persistem dinamicamente na sua camada de dados, via JPA, Hibernate, ou qualquer outro framework que atue nesse paradigma.
Nao entendi o que você disse, tem como explicar melhor?
Seu dominio é um DAO que se projeta desenhado um pedaços de classes que são refletidas para objetos que persistem dinamicamente na sua camada de dados, via JPA, Hibernate, ou qualquer outro framework que atue nesse paradigma.
Nao entendi o que você disse, tem como explicar melhor?
DAO é um abstração, que por reflection você persiste dados, você usa determinado patterns(seja Façade, Adapter etc…) para seu domain logic a ser projetado, de forma direta ao controle para camada de dados entre outras que visam comportamento,por frameworks para encapsular essas classe, à contexto de soluções como JPA, HIBERNATE.
Usar microcontainer é melhor usar um Pattern Adapter usando Ruby, o spring é uma filosofia muito mais dinamica, dividir para conquistar trabalhando com o aspecto de DAO.
Fórum não é lugar para codificar, Duran. Escreva em português entendível, por favor.
Fórum não é lugar para codificar, Duran. Escreva em português entendível, por favor.
Não precisa comprar as minhas idéias, mas fica a vontade para vender as suas.
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?
Alessandro ,
O que é caro para um microcontainer como o Spring ?
javaranch, eu não fiz uma afirmação, fiz uma pergunta.
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 !
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).
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
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.
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.
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ó.
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?
Descordo , MESMO sendo um webservice contract-first , poderia-se ter feito algo bem mais intuitivo e produtivo.
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
Eu só vejo você nesse tipo de tópico, só.
assim vc tem o que falar nos topicos 
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.
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 :lol:
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” :lol: :lol: :lol: :lol:
:thumbup:
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…
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.