[quote=nofan][quote=Luca]
E vida longa ao ruby, rails e outras coisas livres dos padrões feitos por comitês…
Luca[/quote]
Qual é exatamente o problema de ser um padrão feito por um comitê ??[/quote]
Muito provavelmente pelo mesmo motivo que no Brasil tudo é feito aos frangalhos…
O tal imediatismo, que na informatica gera um grande problema de fornecedor.
[quote=chun][quote=bobmoe][quote=Luca]Olá
[quote=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[/quote]
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
[/quote]
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. [/quote]
Complicado ? Acho melhor voce dar uma olhada nos screencasts sobre Java EE 6 utilizando NetBeans e Glassfish v3.
[/quote]
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.
[quote=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)
[/quote]
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.
[quote=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.
[/quote]
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.
[quote=chun]JBoss é uma vergonha.
[/quote]
Não entendi. Pode explicar o motivo?
[quote=HarryPodre][quote=chun]JBoss é uma vergonha.
[/quote]
Não entendi. Pode explicar o motivo?[/quote]
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.
[quote=chun][quote=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)
[/quote]
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.
[/quote]
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.[/quote]
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
[quote=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.
[/quote]
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.
[quote=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
[/quote]
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? [/quote]
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…