Lançado o Spring 3.0 final

seria esse um bom incentivo/oportunidade para aprender spring ?

Hmm, muito boa notícia.

Eu não uso Spring e não adoto em meus projetos. Mesmo assim é muito bom ter boas alternativas para quem quer usar features J2EE sem usar EJB e afins. Digo isso não apenas pelo Spring core, mas pelo Acegy/Security e os demais projetos que são todos muito bons.

Mas e aquela iniciativa que o Spring tinha de rodar Spring distribuído? Evoluiu?

Legal vi no twitter do Rod Johnson de manhã.

E algumas horas depois a SpringSource já liberou o Grails 1.2 RC2 com Spring 3.

Suporte a REST e SpEl são as novidades mais interessantes.

Vale a pena sair do estável 2.5???

Mas essa versão é estável.

Bom, estou usando (projetos em desenvolvimento) o RC2 para o básico (DI, Transaction control etc) e está muito bem, obrigado. Vou baixar a versão final e continuar.

Paz e bem!

puxa legal…

mais um lançamento para esses dias…

Pois é, esses ultimos dias tem rolado mta novidade… Q bom!

[]s!

Releases bombando!

Java vai dar uma alavancada.

Ótima noticia… agora é só bombar ele!!

Como eu sempre digo , em tempos de Java EE 6 , Spring perdeu muito do seu charme

Olha soh quantas JSR suportadas… logo logo o Spring implementar JAva EE 6 e pronto… fica tudo a mesma coisa

Olá

chun:

Como eu sempre digo , em tempos de Java EE 6 , Spring perdeu muito do seu charme

Olha soh quantas JSR suportadas… logo logo o Spring implementar JAva EE 6 e pronto… fica tudo a mesma coisa :P

Não foi o Spring que perdeu o charme, é o JEE que está começando a fazer sentido. Quanto mais gente da vida real, do Hibernate, do Spring, etc. participar do JEE melhor. Quando era só dos teóricos dos comitês da Sun era lotado de inutilidades. O Spring foi criado justamente porque algumas coisas do JEE antigo eram imbecís. Na versão seguinte ficaram apenas burras, mais outra versão somente tolas. Agora está quase bom. Provavelmente no JEE 7 fique bom (talvez o JEE 6 sem JSF já seja de regular para bom…)

[]s
Luca

Luca,

Quem está implementando as JSR eh a SpringSource , e não o contrario.

Se alguem tem algum tipo de credito nas spects estarem mais polidas , este alguem é o Gavin King , e não o sem noção do Rod Johnson.

Por anos o Spring foi inundado de xmls gigantes e bem mais ridiculos do que os do J2EE…

Comparado a outras solucoes , as apresentadas pelo spring sempre são dotadas de complexidade desnecessaria (Alguem ai já brincou com Spring MVC , ou Spring WS , ou Spring LDAP ? PELO AMOR DE DEUS !!!)

Agora a SpringSource esta correndo para implementar os padroes , isso eh a prova de que padrões sao importantes…

E padroes nunca vão suprir 100% dos casos. (talvez nem 80%)

Olá

Impossível, nenhum ser humano seria capaz.

Não conheci outras soluções. O Srping sempre foi único na proposta de se evitar os EJBs antigos

Brinquei e gostei, bem melhor do que o que havia na época.

E vida longa ao ruby, rails e outras coisas livres dos padrões feitos por comitês…

[]s
Luca

Luca:

Olá

chun:

Como eu sempre digo , em tempos de Java EE 6 , Spring perdeu muito do seu charme

Olha soh quantas JSR suportadas… logo logo o Spring implementar JAva EE 6 e pronto… fica tudo a mesma coisa :P

Não foi o Spring que perdeu o charme, é o JEE que está começando a fazer sentido. Quanto mais gente da vida real, do Hibernate, do Spring, etc. participar do JEE melhor. Quando era só dos teóricos dos comitês da Sun era lotado de inutilidades. O Spring foi criado justamente porque algumas coisas do JEE antigo eram imbecís. Na versão seguinte ficaram apenas burras, mais outra versão somente tolas. Agora está quase bom. Provavelmente no JEE 7 fique bom (talvez o JEE 6 sem JSF já seja de regular para bom…)

[]s
Luca

eu ainda acho os application servers complicados demais… e não vai adiantar idéias enxutas enquanto continuarem rodando em algo tão complicado de usar.

Luca:

Olá

Impossível, nenhum ser humano seria capaz.

Para voce ver, como será que o Spring conseguiu consquitar este espaço que era do J2EE 1.4 ?

O detalhe eh que voce “comeu” um pedaço do que eu disse, “outras soluções no geral” , EJBs são de proposito especifico e não geral. Eu vou levar em conseracao a sua afirmacao contra EJB uma referencia a EJB’s de versoes anteriores ao 5.0, prq gerenciar e trabalhar com EJB’s no 5.0 é bem mais facil que mander duzias de XML’s do Spring.

Luca:

Brinquei e gostei, bem melhor do que o que havia na época.

E vida longa ao ruby, rails e outras coisas livres dos padrões feitos por comitês…

[]s
Luca

Voce deve estar brincando, Spring-WS é um aborto da natureza, se você nunca gostou dos EJB’s do J2EE 1.4 , nunca seria capaz de utilizar tamanha porcaria como o Spring-WS… (por mais que ele seja contract-first)

E por final …

Viva o Single Vendor Lock IN !

Luca:

E vida longa ao ruby, rails e outras coisas livres dos padrões feitos por comitês…

Luca

Qual é exatamente o problema de ser um padrão feito por um comitê ??

bobmoe:

Luca:

Olá

chun:

Como eu sempre digo , em tempos de Java EE 6 , Spring perdeu muito do seu charme

Olha soh quantas JSR suportadas… logo logo o Spring implementar JAva EE 6 e pronto… fica tudo a mesma coisa :P

Não foi o Spring que perdeu o charme, é o JEE que está começando a fazer sentido. Quanto mais gente da vida real, do Hibernate, do Spring, etc. participar do JEE melhor. Quando era só dos teóricos dos comitês da Sun era lotado de inutilidades. O Spring foi criado justamente porque algumas coisas do JEE antigo eram imbecís. Na versão seguinte ficaram apenas burras, mais outra versão somente tolas. Agora está quase bom. Provavelmente no JEE 7 fique bom (talvez o JEE 6 sem JSF já seja de regular para bom…)

[]s
Luca

eu ainda acho os application servers complicados demais… e não vai adiantar idéias enxutas enquanto continuarem rodando em algo tão complicado de usar.

Complicado ? Acho melhor voce dar uma olhada nos screencasts sobre Java EE 6 utilizando NetBeans e Glassfish v3.

nofan:

Luca:

E vida longa ao ruby, rails e outras coisas livres dos padrões feitos por comitês…

Luca

Qual é exatamente o problema de ser um padrão feito por um comitê ??

Muito provavelmente pelo mesmo motivo que no Brasil tudo é feito aos frangalhos…

O tal imediatismo, que na informatica gera um grande problema de fornecedor.

chun:

bobmoe:

Luca:

Olá

chun:

Como eu sempre digo , em tempos de Java EE 6 , Spring perdeu muito do seu charme

Olha soh quantas JSR suportadas… logo logo o Spring implementar JAva EE 6 e pronto… fica tudo a mesma coisa :P

Não foi o Spring que perdeu o charme, é o JEE que está começando a fazer sentido. Quanto mais gente da vida real, do Hibernate, do Spring, etc. participar do JEE melhor. Quando era só dos teóricos dos comitês da Sun era lotado de inutilidades. O Spring foi criado justamente porque algumas coisas do JEE antigo eram imbecís. Na versão seguinte ficaram apenas burras, mais outra versão somente tolas. Agora está quase bom. Provavelmente no JEE 7 fique bom (talvez o JEE 6 sem JSF já seja de regular para bom…)

[]s
Luca

eu ainda acho os application servers complicados demais… e não vai adiantar idéias enxutas enquanto continuarem rodando em algo tão complicado de usar.

Complicado ? Acho melhor voce dar uma olhada nos screencasts sobre Java EE 6 utilizando NetBeans e Glassfish v3.

pois é chun, estou falando isso baseado no jboss atual. vc já viu como é simples um deploy do vraptor ou rails comparado a qualquer coisa que precise do jboss (seam por exemplo)? é impresisonante como a estrutura é complicada. é usando apenas o tomcat que a gente percebe a diferença na produtividade.

JBoss é uma vergonha.

Olá

Correto. O Srping nasceu por causa daquele monte de arquivos necessários para um simples EJB (remoto devido a burrice dos caras da Sun)

Os comitês do Java em geral reunem um monte de teóricos mais um monte de incompetentes de empresas mastodônticas tipo IBM, Oracle e outras para ficar um monte de tempo discutindo como complicar mais a vida do Java porque na cabeça deles Java só serve para enterprise.

Foram os comitês em volta do Java que inventaram coisas do tipo EJBs, JSFs e outras porcarias. O Java já estaria morto se não fosse pelo que foi criado FORA dos comitês (Hibernate, Lucene, o próprio Spring nos tempos dos antigos EJBs e os diversos frameworks web mais fáceis de usar do que JSFs). Os comitês abandonaram tudo que não é enterprise, ou seja, quase todo o mercado de desenvolvimento web.

E o caminho ficou aberto para tudo que não é regulado por comitês. Se são frangalhos, TUDO que fiz na vida fora o Java, são frangalhos. Usei durante anos: Fortran assembler, C, C++, Clipper e nenhuma era regulada por comitês do tipo Java, que é a única linguagem que usei na vida em que muitos discutem anos e anos se vai entrar X ou Y.

[]s
Luca

Pra mim EJB 3.0 é uma cópia descarada de funcionalidades do Spring. ponto final.

O spring sempre foi percursor em muitos aspectos, mas eles não decidem sozinho a especificação, e nem tudo no Spring é feito do melhor jeito possivel, vide Spring WS, o do EJB3 é muito melhor.

Apesar de implementarem a Spec, eu acho que eles sempre provem soluções tão boas ou até melhores que a spec atual. Além de evoluirem muito mais rápido, já que não tem toda a burocratização do comite. É a mesma coisa do Hibernate, sempre vai estar um passo a frente da Spec.

Luca:

Olá

Correto. O Srping nasceu por causa daquele monte de arquivos necessários para um simples EJB (remoto devido a burrice dos caras da Sun)

Burrice depende do ponto de vista, EJB nasceu para ser ENTERPRISE e apenas em ambientes realmente ENTERPRISE , se for pensar assim , interfaces remotas são essenciais para CLUSTERIZAR acesso estilo CORBA, que na epoca era a tecnologia dominante. Agora voce quer continuar chorando com coisas do J2EE 1.4 ? Comparemos com os dias de hoje por favor.

mario.fts:

Pra mim EJB 3.0 é uma cópia descarada de funcionalidades do Spring. ponto final.

O spring sempre foi percursor em muitos aspectos, mas eles não decidem sozinho a especificação, e nem tudo no Spring é feito do melhor jeito possivel, vide Spring WS, o do EJB3 é muito melhor.

Apesar de implementarem a Spec, eu acho que eles sempre provem soluções tão boas ou até melhores que a spec atual. Além de evoluirem muito mais rápido, já que não tem toda a burocratização do comite. É a mesma coisa do Hibernate, sempre vai estar um passo a frente da Spec.

Copia ? Acho que voce precisa ler mais sobre o surgimento dos EJB’s , e Spring nem existia , veio depois.

EJB 3 é XML-less , Spring até MUITO pouco tempo atras nao era nenhum pouco.

chun:

JBoss é uma vergonha.

Não entendi. Pode explicar o motivo?

HarryPodre:

chun:

JBoss é uma vergonha.

Não entendi. Pode explicar o motivo?

Porque tudo nele , é ao estido dele e sempre da forma mais precaria possivel. Compare o JBoss como solucao com os containers do mercado OpenSource…

Geronimo, Glassfish, JonAS…

Ai voce vai entender o que eu digo.

chun:

Luca:

Olá

Correto. O Srping nasceu por causa daquele monte de arquivos necessários para um simples EJB (remoto devido a burrice dos caras da Sun)

Burrice depende do ponto de vista, EJB nasceu para ser ENTERPRISE e apenas em ambientes realmente ENTERPRISE , se for pensar assim , interfaces remotas são essenciais para CLUSTERIZAR acesso estilo CORBA, que na epoca era a tecnologia dominante. Agora voce quer continuar chorando com coisas do J2EE 1.4 ? Comparemos com os dias de hoje por favor.

essa palavra enterprise sempre usaram como desculpa pra coisas exageradas. parace q ela da uma sensação de seguraça aos empresários… coitados.

J2EE 1.4 era para coisas exageradas mesmo…

Quem usou para coisa pequenas ou medias , acabou se quebrando.

Copia ? Acho que voce precisa ler mais sobre o surgimento dos EJB’s , e Spring nem existia , veio depois.

EJB 3 é XML-less , Spring até MUITO pouco tempo atras nao era nenhum pouco.

Eu sei disso. por isso escrevi EJB3.

Olá

O EJB 3.0 foi uma das raras vezes que a Sun escutou o mercado. Foi beber na fonte do Hibernate e do Gavin King do JBoss. Se dependesse daquelas bestas que um dia criaram coisas do tipo JAX-RPC, o EJB 3.0 seria apenas uma evolução dos EJBs 2.x. Portanto, nada a ver com o Spring.

O que o Spring tem de bom é ter sido feito por bons programadores. Li os livros do Rod Johnson e não consigo entender como o Chun pode achar o Rod sem noção. Realmente hoje fico meio sem saber para que serve o Spring. Mas não posso ignorar a história.

Acompanho o Glassfish desde antes da primeira versão. Melhorou bastante na última versão. Mas ainda é difícil de recomendar alguma empresa que troque seu JBoss por ele, principalmente agora que ninguém sabe que fim a Oracle dará a ele. O Gerônimo e o Jonas não conheço ninguém que use e nem sei se ainda estão em desenvolvimento.

[]s
Luca

Luca:

Olá

O EJB 3.0 foi uma das raras vezes que a Sun escutou o mercado. Foi beber na fonte do Hibernate e do Gavin King do JBoss. Se dependesse daquelas bestas que um dia criaram coisas do tipo JAX-RPC, o EJB 3.0 seria apenas uma evolução dos EJBs 2.x. Portanto, nada a ver com o Spring.

Lembrando que o Gavin nunca fez nada realmente espetacular dentro da JBoss , sempre continuou na linha de pensamento dele… entao se esse “Gavin do Jboss” foi uma tentativa de engrandecer a JBoss, não vale para este quisito.

Era justamente aonde eu gostaria de chegar, foi… Spring FOI uma alternativa aos tempos tenebrosos do EJB gordo e lento… em dias de Java EE 6 , só usa Spring quem já esta acostumado, nao tem porque utilizar mais um framework que faz coisas que já vem “de fabrica” no Java EE.

Quer IoC ? Usa google guice !!! MUITO mais facil , MUITO menor e com uma curva MUITO mais plana.

Utilizei por muito tempo o JBoss, parei de usar ele prq essa mania besta do pessoal de lá em “meter a mao nos padroes” , as coisas no JBoss 4.x sempre eram “+/-” compativeis com Java EE , e quando lancaram aquele FRANKEITEIN do JBoss 4.x com EJB3 tive a certeza de que sempre vão discutir coisas obvias, simplesmente inaceitavel levar mais de 3 anos para implementar um padrão que só veio para adicionar…

Se eu quisesse ficar fazendo aplicativos utilizando o TOMCAT , nao optaria pelo JBOSS (claro ! para que um EJB container engordando tudo ?), e utilizar J2EE 1.4 quando o 5 era muito superior tambem nao faz a cabeca de ninguem… logo… JBoss fora do baralho.

Mas respeito sua opiniao.

Luca:

Olá

O EJB 3.0 foi uma das raras vezes que a Sun escutou o mercado. … Portanto, nada a ver com o Spring.
…
[]s
Luca

Acho que me expressei mal. O que eu quiz dizer foi exatamente isso, que a Sun foi no mercado ver o que o mercado usava. E o mercado estava usando Spring, que trazia todas as funcionalidades que o JEE precisava num lugar só. É claro que eles não eram os unicos, eu usei muito o PicoContainer, se for só pra fazer IoC é muito mais leve (e fácil na minha opnião, pelo menos pros casos default) do que o Spring. Acho que vc explicou melhor do que eu.

Mas ainda discordo do fato do EJB3 não ser uma “Evolução” do Spring. Por isso acho que tem a ver sim, afinal, eles competem em um mercado que antes era dominado pelo Spring.

Ainda prefiro o Spring MVC do que o JSF. O JSF 2.0 poderia ter sido melhorzinho, mas…
E sim, EJB 3 são melhores que o Spring, se comparar no aspecto de Security, Annotations. Agora com o GlassFish v3, nem sei se realmente justifica ter um Tomcat da vida. Talvez nem o Jetty se justifica. Diferente do troço do JBoss, cada vez mais pesadão e sempre levantando a bandeira da sua complexidade de configuração (agora ele tem administrador descente pelo menos?).

Oi chun, realmente quem implementa as JSRs é a SS e não o contrário, porém, isto não significa que as idéias propostas do JSR não foram originadas de providers de soluções bem longe da Sun. @Inject por exemplo, quem se importava com DI antes do Guice, Spring, Pico aparecer? A sun que não. Quem se importava com ORM descente antes do hibernate? A sun que não.

Quanto aos xmls, qual o problema exato deles? A configuração? a Spring IDE não ajuda? eu mesmo prefiro deixar configuração fora do meu código. É questão de gosto, e antes de anotações, qual era o tipo de metadados a se utilizar? portanto, agora que o spring pode ser configurado por convenção, anotação e xml, não tem muito a se reclamar.

Qual o problema do Spring MVC? tu acha complexo? Eu vejo bem pelo contrário, muito mais simples do muito framework web por aí, minha opinião.

e é estranho tu reclamar tanto do spring, sendo que em outro tópico já vi você defendendo uma plataforma baseada em spring.

[]s

Por curiosidade, o que vc acha complexo de configurar no jboss?

Por curiosidade, o que vc acha complexo de configurar no jboss?

Ia perguntar a mesma coisa. Nunca tive problemas e a versão 5 ainda simplificou muito as configurações. A 5.1 mais ainda.

Spring surgiu a partir das deficiências do EJB 2.x. Claro que o EJB 3 evolui muito(e a principal mudança foi em relação aos Entitys, e nisso ele se baseou enormemente no Hibernate, não no Spring), mas dizer que depois dele o Spring não tem mais utilidade é um pouquinho demais. Lembrem-se, nem todo sistema é feito do zero, e mais, ele pode ser usado como opção em casos em que quero usar controle transacional, mas não quero/posso usar um Application Server, sem contar que ele conversa muito bem com o JEE. Já viram como é elegante eliminar o clássico Business Delegate e seu Service Locator usando Spring? A integração que o Spring tem com Velocity, Freemaker, Javamail, etc… Hoje não dá pra falar que se usa Spring pra substituir EJB’s, e sim como facilitador de integração com muitas tecnologias que existem por ai, inclusive o JEE.

Sobre complexidade de configuração, configurar uma app no Jboss é mais difícil que um Weblogic da vida?? Sei não viu…

Olá

Concordo 100% com o que escreveu, inclusive com o que citei. Foi o melhor resumo do tópico. Eu mesmo escrevi que hoje em dia o Spring não é mais tão necessário como antes. Mas é óbvio que ainda tem muitas utilidades.

Parabéns

[]s
Luca

É isso Luca…

Acredito que o Spring é, e ainda deve continuar sendo forte, pois seu objetivo não é mais necessariamente substituir JEE. Acredito que foi um bom direcionamento da turma do Spring (Spring em contexto geral) não fazer do mesmo puramente um concorrente ao JEE, coisa que acontece muito quando falamos especificamente de frameworks Web (Struts X JSF X Mentawai x Spring MVC x etcs…).

Vejo que existe um criticismo às vezes exagerado quanto ao Spring, pois muita gente acha que ele apenas serve pra substituir o EJB… Pra quem ainda não sabe das possibilidades, é só dar uma olhadinha no overview e nos tópicos de referência da documentação e na lista de projetos acessórios pra se ter uma idéia.

Pra quem desenvolve aplicações RIA com flex, ele possui uma abstração bem legal para o BlazeDS, é o tipo de facilitador que o JEE não possui, por mais que seu back end seja de fato Entreprise

Acho que é isso mesmo. Ele começou pra simplificar a complexidade do EJB e hoje em dia evoluiu pra várias outras facilidades. Quem usava ele somente como alternativa a EJB não vê mais muita utilidade nele, mas quem utiliza os outros frameworks do Spring vê que ainda tem muito mais. Mas é verdade que ele perdeu uma boa parte do brilho de outrora.

O JEE 5 foi um marco pra Sun porque foi o momento que ela começou a se voltar para o mercado e a atender várias demandas. E continuou fazendo isso no JEE6, isso foi muito bom.

Pois é marcosalex ,

Isso se deve aa natureza das mudanças. Tem sempre aquele momento em que aparece algo inovador, cria-se toda uma atmosfera, uma luz, por se tratar de algo novo, mas quando perde o caráter inovador, o brilho realmente se perde. É como alguma nova ideia/aquisição do Google ou os finais de Jogos Mortais (2 a 6). Ao menos em Jogos Mortais, por mais que você diga “poxa achava que ia acontecer algo diferente”, você já espera que aconteça algo imprevisível(ainda que você não saiba o quê).

Em termos de mapeamento objeto relacional dificilmente ficaremos “encantados” com o Hibernate ou qualquer nova implementação de JPA, por que deixou de ser novidade, e passou a ser comum pra muitos desenvolvedores. O mais importante é que ele continue tendo uma razão de ser. O hibernate é um bom exemplo, ele não perdeu sua razão, passou a ser uma implementação de uma especificação, e o surgimento da mesma só corrobora o seu valor.

Me parece um pouco controverso tecer elogios rasgados pro EJB 3.0 e chamar o Rod Johnson de sem noção, sendo que ele participou da spec do Java EE6.

chun:

Luca,

Quem está implementando as JSR eh a SpringSource , e não o contrario.

Acho q o q ele quis dizer foi justamente isso: o Java tah ficando bom o suficiente a ponto de o Spring começar a correr atrás…

chun:

Luca,
Quem está implementando as JSR eh a SpringSource , e não o contrario.

Pode até ser ridículo, mais o nível de complexidade sempre foi menor

Já desenvolvi com Spring LDAP e MVC. Não consegui enchergar a complexidade, nessa ultima versão pude fazer alguns testes com REST e adotei Spring MVC como MVC top 1. A complexidade do LDAP esta no na própria arquitetura de LDAP, não é culpa do Spring…

A maioria dos padrões da JEE são zuados, a partir do momento que vc utiliza mais de 3 padrões no seu projeto a arquitetura deixa de ser aconselhavel, é muita gambi em um lugar só… o Spring esta adotando o padrão do mercado sendo coerente, nem tudo que sai da JEE é 100% confiável…

peerless:

chun:

…

Qual o problema do Spring MVC? tu acha complexo? Eu vejo bem pelo contrário, muito mais simples do muito framework web por aí, minha opinião.

[]s

Sábias palavras… Concordo totalmente! O web flow pode ser um pouco complexo, mais o MVC é muito simples e fácil.

asaudate:

chun:

Luca,

Quem está implementando as JSR eh a SpringSource , e não o contrario.

Acho q o q ele quis dizer foi justamente isso: o Java tah ficando bom o suficiente a ponto de o Spring começar a correr atrás…

Não é que JEE esteja ficando boa… Estão copiando bem as frameworks do mercado e colocando como padrão. É uma forma de ofuscar projetos alternativos… O pior disso que eles ficam com os créditos hehe

Em tempos de JEE 6, em se tratando de Desenvolvimento Java Enterprise, o JBoss não seria “a melhor opção” para AS? :shock:

Em tempos de JEE 6, em se tratando de Desenvolvimento Java Enterprise, o Spring não seria “a melhor opção” de framework? :roll:

:?:

rato*locoNovamente:

A Jboss não precisa ser engrandecida por ninguem ela ja e o maximo por si propria,a proposito pra que Spring se a Jboss tem o seam isso sim e um framework top de linha.

O máximo??? Vc tá comparando uma faca(Seam) com canivete suiço(Spring)!!!

“Seam is a powerful open source development platform for building rich Internet applications in Java. Seam integrates technologies such as Asynchronous JavaScript and XML (AJAX), JavaServer Faces (JSF), Java Persistence (JPA), Enterprise Java Beans (EJB 3.0) and Business Process Management (BPM) into a unified full-stack solution, complete with sophisticated tooling.”

O Spring é não apenas isso… Ele é muito mais robusto!!!

ratolocoNovamente:

dders:

ratolocoNovamente:

A Jboss não precisa ser engrandecida por ninguem ela ja e o maximo por si propria,a proposito pra que Spring se a Jboss tem o seam isso sim e um framework top de linha.

O máximo??? Vc tá comparando uma faca(Seam) com canivete suiço(Spring)!!!

Um canivete suico de inutilidades com certeza,eu que trabalho somente com aplicacoes web,jamais trocaria o seam que é um Frame… de alto nivel por uma lata velha e cheia de quinquilharias inuteis como o Spring.

É inutil pq vc nunca deve ter passado de um crud!!!

rato*locoNovamente:

O Spring é não apenas isso… Ele é muito mais robusto!!!

Robusto,o que é robusto pra vc??

Analisa o escopo do Seam e compara com Spring? Pelo menos teve o trabalho de verificar???

Não faz sentido comparar o Seam com o Spring, o Spring além te tudo é um conjunto de tecnologias e da suporte as coisas mais complexas que vc possa necessitar… É lógico que em aplicações de pequeno porte não ira usar 20% da disponibilidade de recursos do Spring.

Provavél que nunca tenha se deparado com logs complexos, auditoria, acesso a base ldap, processamento assíncrono, rest, etc… Vc tem tudo isso em um único lugar, integrado de uma forma simples, sem anexar a dependência de diversos frameworks(Remendo geral).

:?: :?:

Minha opinião sincera em comparação do Spring atual com o EJB atual: muito XML no Spring.
Acho que pra ficar bom, precisa tirar aquele monte de XML. Se o Spring fizer mais do que vem fazendo, sempre adotando anotações padrão, seria o ideal, removendo principalmente aquele XML que ainda é necessário.
Embora no Spring 3.0 tenham diminuído muito o número de configurações no XML, ainda é necessário, onde deveria ser apenas opcional.

Mais alguma opinião sincera? É bem-vinda!

O Srping 3 eliminou os spring-service.xml e spring-dao.xml. Agora é tudo com anotações.

No MVC também, não precisa mais criar o spring-controller.xml e dizer neles o que faz cada controller e para onde envia as informações, essas configurações agora também são feitas por anotações.

Eu uso a versão 2.x do Spring e mesmo com xml de mais, depois que vc aprende a mexer, não larga mais, principalmente pela questão de injeção de dependencias, muito bom isso.

Com a nova versão, vai ficar muito mais fácil com certeza, mas o antigo com os xmls já era muito bom.