[quote]Repito , voce acha que UM MES de lançada uma versão nova de APP Server toda a galera pode AUTOMAGICAMENTE sair colocando ela…
[/quote]
Por isso empresas como Oracle, Red Hat, IBM e tantas outras possuem um serviço para auxiliar clientes na migração de servidores e ASSUMIR qualquer problema relacionado a isso. Cabe você pagar pelo serviço ou se garantir para faze-lo.
[quote]
Ué… se para “CORRIGIR” o Weld 1.0 tenho que comprar o GF , o que isso quer dizer ? 1+1=2 (detalhe , estes bugs estão marcados como WELD-INT-REQUIRED , ou seja , nem a versão PAGA teve correção. E desculpinha esfarrapada do “USE POR SUA PROPRIA CONTA E RISCO”.[/quote]
Significa que se você exige que uma correção seja feita, ou você faz uma, ou você paga por ela, ou espera a comunidade fazer (ja disse isso). A unica empresa que oferece suporte ao WELD e bugfix garantido por suporte é a Oracle (woow, mas não é um produto da JBoss? Não, ele é um projeto da comunidade hospedado no jboss.org e patrocinado pela Red Hat). A Red Hat lançara no final deste ano / começo do ano que vem o JBoss EAP 6 que inclui o Weld como implementação do CDI. Neste caso você poderá contar com o suporte da mesma para correções de bugs e tudo mais. Mas hoje se você exige isso, pague a Oracle ou qualquer consultoria que presta serviços para softwares open sources para te fazer o serviço. Se a versão paga do Glassfish apresenta algum problema, você como cliente tem todo o respaldo legal para exigir uma correção. Agora, se você não quer desembolsar dinheiro algum e não sabe como resolver determinado problema que voc6e enfrenta em produção, então sim: USE POR SUA PROPRIA CONTA E RISCO, e tente se garantir no que faz :twisted:
Ai que voce se engana novamente , eu nao exijo nada porque não pago por nada…
A questão é a falta de comprometimento com o usuário do WELD por parte da JBoss… sabendo de problemas desta envergadura nem backport para a 1.0 foi cogitado, tudo com a premissa do “USE POR SUA CONTA E RISCO”
Disse que isso é que fod… o software livre, e reafirmo , incrível como o pessoa do SL fica ofendido quando cobra-se um pingo de responsabilidade… mas estes mesmos que se ofendem estão lá em palestras para dizer o “QUANTO É BOM SER MARAVILHOSAMENTE LIVRE”.
Emfim , continuo achando um projeto de qualidade questionável , com certeza isso pode mudar em um futuro… quem sabe quando eu tiver a opção de mudar para outro
Sou amante do SL , mas não coloco um freio de burro e fecho meus olhos para problemas evidentes deste modelo.
ps: Detalhe , viu a quantidade de opção que eu tenho certificada JAva EE 6 ? Nem trocar para o JBoss não posso , pelo visto esta minha “inexperiência” esta custando caro :shock:
Cara, entenda, não existe backport para o mysql, para o postgres, para o Hibernate, para o Spring, para o Seam, para o Primefaces, assim como não existe para o Weld ! As versões menores que são lançadas possuem o fix acumulativo da versão anterior. Não é um crime da comunidade responsável por manter o Weld, a maioria dos frameworks open sources funcionam desta maneira. Quem faz backport são as empresas que produtizam as ferramentas, para que seus clientes possam utlizar uma mesma versão por longos anos (no caso da red hat 7 anos, da Oracle eu não sei), com os patches sendo aplicados para sua versão atual. Se a oracle não fez o backport para o servidor de aplicação deles, não cabe aos desenvolvedores do Weld o fazerem.
Não é uma questão de comprometimento, é uma questão de escolha. Se você não quer o apoio da Oracle, faça o backport você mesmo. Aliás existem vários tutorias na internet mostrando como portar os fix do Weld 1.1.0 para o Weld 1.0.1
[quote=Alessandro Lazarotti]Cara, entenda, não existe backport para o mysql, para o postgres, para o Hibernate, para o Spring, para o Seam, para o Primefaces, assim como não existe para o Weld ! As versões menores que são lançadas possuem o fix acumulativo da versão anterior. Não é um crime da comunidade responsável por manter o Weld, a maioria dos frameworks open sources funcionam desta maneira. Quem faz backport são as empresas que produtizam as ferramentas, para que seus clientes possam utlizar uma mesma versão por longos anos (no caso da red hat 7 anos, da Oracle eu não sei), com os patches sendo aplicados para sua versão atual. Se a oracle não fez o backport para o servidor de aplicação deles, não cabe aos desenvolvedores do Weld o fazerem.
Não é uma questão de comprometimento, é uma questão de escolha. Se você não quer o apoio da Oracle, faça o backport você mesmo. Aliás existem vários tutorias na internet mostrando como portar os fix do Weld 1.1.0 para o Weld 1.0.1 ;)[/quote]
Não existe backuport para MySQL ? acho que você anda bem desinformado , procure sobre “ROW LEVEL REPLICATION” e correções de leaks de memoria nas listas do mysql que vc vai ter uma surpresa !
Detalhe , quem mudou FOI O WELD e não o GF , a WELD resolveu usar a SPI … ela tava lá desde a versão 3.0 , quem fez esta alteração impossibilitando a atualização do weld no GF 3.0 foi a JBoss.
Cara… voce realmente está minimizando um bug GRAVE , sem backport e que só foi corrigido nas versões ATUAIS… quem não pode migrar, na sua opinião que “se exploda”. Quando digo falta de comprometimento eu digo isso
A JVM VIVE fazendo backport para versões anteriores de correções importantes…
Do resto, me desculpe caso eu tenha citado o MySQL em não ter backport, realmente ele possui. O que disse mencionando Hibernate, Spring, Primefaces, Seam, Struts, GWT e poderia citar outros frameworks Java como Guice, Axis, Mvel, EclipseLink, etc… é que essa política não é uma obrigatoriedade e nem uma prática comum em qualquer projeto open source. Particularmente falando de bibliotecas/frameworks Java, é algo muito raro. Como disse, isso não impede de você aplicar um patch que esta no uptsream para sua versão atual. Afinal de contar o código é aberto - ou pagar alguém para fazer isso.
Não quero minimizar problema algum, só estou afirmando o tempo todo que o responsável por escolher uma tecnologia e seus componentes é o arquiteto da aplicação. Se o arquiteto da aplicação que você trabalhou optou por usar o Weld 1.0 no Glassfish, sem suporte algum, ele deveria saber dos riscos q estaria assumindo. Optar em usar JavaEE6, mesmo você reafirmando que não se tem opção em escolha, também foi uma escolha dele, não foi? Entende agora o que eu digo por “conta e risco”.
O comprometimento da equipe que trabalha com o Weld é corrigir os bugs, implementar features e fazer passar no TCK. Se ele passou no TCK mas não esta se integrando muto bem com o Glassfish (a mudança da versão 1.0.1 para 1.1 não tem impacto no JBoss 6), talvez o problema não seja exclusivamente do Weld, não é mesmo?
[quote=Alessandro Lazarotti]Uma rápida busca no Google achei esta thread que pode lhe ajudar em aplicar o fix para a sua versão do Weld: http://www.sfwk.org/Community/LeakingOrNot
[/quote]
Hehehe eu SABIA que voce ia colar esta… esta correção não é suficiente , apenas resolve UM LEAK , o do ResolvableBuilder , o TypeDefinition e os bilhares de HashMaps perdidos na memoria ( entre outros) ainda vão continuar lá… como que eu sei ? Prq eu já experimente isso a meses atras
Acorda, voce pesquisou algo que até o cara do dito “post antigo” já tinha testado
Está dificil você entender que eu não tenho outra opção a não ser o WELD ? Hoje infelizmente ele é o unico que passa no TCK e sinceramente achei que existia uma politica mais responsavel por alguem que LIDERA a spec do CDI.
Estes problemas de LEAK ocorrem no JBoss com Weld 1.0 , não é exclusividade do Glassfish. A mudanca sim , tanto que para evitar problemas futuros isso foi mudado.
Repito , o que me preoculpa é algo tão gritante em um componente tão importante do Java EE 6 estar recebendo este descaso no caso do Backport dos bugs gritantes…
Mas tudo bem , espero que daqui para frente não tenhamos mais surpresas desagradáveis como estas.
Mas esta tudo no repositório público, sempre esteve chun. Compile, faça diff, teste e use, de nenhum jeito você terá suporte de alguma empresa mesmo, afinal de contas você não esta pagando por isso. Então arregasse as mangas e faça o backport.
… mais uma vez, no JBoss 6 o Weld 1.1.0 esta redondo e passando com louvor no TCK desde Janeiro.
Se você esta tendo problema com o peixe de vidro, se entenda com a Oracle :twisted:
Você tem razão Fred. Eu já disse umas 4 páginas atrás que essa discussão não era para ser o foco desta thread e para iniciar um novo tópico caso alguém quisesse debater sobre isso (Weld). Mas não funcionou.
Minha participação sobre o assunto “weld” neste tópico esta encerrada.
É muito comum utilizar Seam sem EJB. Para falar a verdade, no livro Seam in Action de Dan Allen a maioria dos exemplos são focados em sua utlizaçao sem EJB.
No Seam2 (JavaEE5), independente de usar EJB, você ainda tem:
DI com gerenciamento de contexto (idéia que gerou o CDI e outros frameworks como Spring WebFlow)
Escopo adicional de conversação
EL extendida com JBossEL
Várias melhorias ao JSF
Sistema de eventos (Component-driven events, aka Observer model)
Frindly URL
Exception Handling
Framework interno para autenticação e segurança
Framework interno para consultas e persistência
Scafolld apartir de entidades ou através de tabelas de banco
Integração extremamente simplificada e goodies para diversas tecnlogias ( jBPM, Drools, Hibernate/JPA, jFreeChart, Captcha, envio de Email, JMS, iText, jExcel, RSS, RestEasy )
E mais várias outras coisas como desenvolvimento de componentes em Groovy, trocar view JSF por Wicket ou GWT, mesclar o sistema de DI ou trocar completamente por Guice ou Spring … enfim, coisa pra caramba
No Seam 3, vários componentes ainda estão para serem lançados. Várias idéias presentes no Seam 2 já foram incluídas no próprio CDI e suas extensões foram para o Seam 3, como os citados em http://relation.to/Bloggers/Seam300FinalReleased
