| Autor |
Mensagem |
|
|
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 
|
 |
|
|
Repito , voce acha que UM MES de lançada uma versão nova de APP Server toda a galera pode AUTOMAGICAMENTE sair colocando ela...
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.
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".
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 
|
|
|
|
Quem está xoramingando aqui é você , é uma BOMBA e ponto final.(antes mais do que hoje)
Argumento do tipo feio, chato, bobalhão... passo
Quem entrou "numas" de defender o indefensável foi voce e não eu. Quem justifica a pessima qualidade da versão 1.0 do WELD culpando "testes" dos outros é você e não eu.
Não defendo o JBoss3, o Hibernate 1.8, Struts 1 e nem o ADF Faces quando foi para o Apache com o nome Trinidad e nem script Maven usando Jelly. Assim como não defendo o pioneiro Weld 1.0 para uso em produção. Não defendo o indefensável, apenas acho ridículo você culpar alguém por sua inexperiência em colocar sistemas em produção
O dia que você começar a LER antes de escrever , VERIFICAR o historico dos fatos antes de falar bobagem , talvez pare de dar sugestões mágicas do tipo "Tire o @Inject e pare de reclamar"
Não fui eu que sugeri isso, foi o blog que você linkou, isso é, se você leu o blog antes de publica-lo aqui
Agora virou culpa da Oracle que não corrigiu as cagadas do "Maravilhosamente Opensource" Weld.
Jamais disso isso. Só disse, e repito, que se você nao tem aptidão para corrigir um problema no software open source que você utliza, ou você tem que esperar uma correção da comunidade (sem ficar chorando), ou tem que pagar alguém como a Oracle para fazer isso pra você (já que você optou pelo Glassfish, claro).
|
|
|
|
Cansei de ler você reclamar sem base alguma.
Mas uma vez eu repito:
Trabalha com open source e não tem conhecimento para corrigir um problema e exige que isso seja feito em seu timeline? Pague para fazerem isso por você.
O Weld é componente integral do Glassfish. Assim como a Red Hat suporta todos os componentes que fazem parte de seu servidor (JBoss EAP), a Oracle faz o mesmo com os dele (Glassfish/Weblogic).
Pare de reclamar e pague alguém para fazer o serviço que você não esta apto a fazer ou seja menos beberrão.
PS: Eu não disse para você simplesmente tirar os @Inject, eu citei o exemplo do blog que você mesmo postou, onde o desenvolvedor detectou um problema no Weld e não colocou o projeto em produção com o mesmo, ele substituiu a tecnologia. Mas vc já tinha entendido isso... então deixa pra lá
|
|
|
|
Se voce usa só @Inject em seus projetos é uma pena. Está perdendo uma API fascinante , e melhor de tudo , um padrão.
Interessante. Leia a Mundo Java edição 40 (março/2010) e você saberá o que uso em meus projetos.
|
|
|
|
Como já disse o fix para performance já estava disponível desde novembro. Se vc desejasse uma versão final do weld, teria a disposição em janeiro.
Mas se você não se sente confortável em esperar uma versão "estável" entrar no ar gratuitamente para o seu uso em produção ou não possui conhecimento e segurança técnica para corrigir um problema em um código aberto, pague alguém para fazer o serviço
Até onde eu sei a Oracle oferece contrato de suporte para o Glassfish. Faça isso e cobre deles em contrato que você esta enfrentando problemas em componentes do servidor em produção. Agora, se você quer esperar que um produto open source satisfaça ou seu desejo de timeline, desculpe, mas você tem que saber se virar um pouco mais sozinho ou esperar que a comunidade resolva o problema pra você.
|
|
|
|
Bom, pelo visto acabaram seus argumentos.
Continuei postando aqui apenas para que links sobre notícias de blogs antigos (como os benchmarks já ultrapassados que o "chun(?)" postou) não deixasse por entender algo que não é realidade a algum tempo.
Esse não era o tópico ideal pra isso, mas quem ficou com dúvida no que postei e quiser debater sobre performance do Weld em alguma outra thread pode me convidar por MP.
|
|
|
|
Voce leu o que escrevi ? PASSEI e não estou PASSANDO com problemas de leak no WELD...
Ué, até agora, você estava "desesperado" com o Weld, falando que ele é uma "bomba", etc
Escrevi aqui prq voce simplesmente MINIMIZOU um problema GRAVE de qualidade do WELD e botou na bund... da dita "comunidade", e munido de uma desculpa esfarrapada de testes simplesmente culpou quem USA por um LEAK criado por quem PROGRAMOU.
Pela décima vez, o Weld é open source, com vários commiters que inclusive não são da Red Hat e com toda a comunidade convidada para relatar bugs e apresentar patches.
Se você detectou um problema grave e colocou em produção mesmo assim, o problema é seu, a ingenuidade é sua.
ps: Ué , deixei de ser troll ?
De acordo com todo o pessoal do GUJ que conheço... continua sendo
ps2: Para quem é tão especialista em testes usar uma versão *BETA* com mais de 40 correcoes adicionais está bem *OUSADO* não ?
Usar uma versão BETA diretamente em produção é ser ousado, mas ninguém lhe disse para fazer isso. Usar em ambiente de teste e verificar que ele esta superior que sua versão atual em produção, isso já é um procedimento aceitável. No entanto, você não precisaria esperar muito, depois de 1 mês que foi feita estas correções já estava disponível a versão final. Ou seja, seu argumento é vazio.
obs: aliás, 40 correções para uma tecnologia em BETA do tamanho do Weld é um úmero muito, muito, muito baixo. ë só vc pegar qualquer issue tracker de projeto deste porte e comparar.
Bom, enfim estou feliz agora em saber que você não esta mais "desesperado", achando que tudo é uma "bomba", como você disse antes. Eu realmente fiquei preocupado por você estar passando por problemas que já não são realidade a algum tempo. Mas tudo bem, já que oq vc diz não é uma verdade absoluta (conforme diz sua assinatura), o sensacionalismo que você posta nas mensagens tbm deve não ser.
|
|
|
|
Agora sobre testes, acredito que você ainda possui uma certa dificuldade em ler o que escrevo (ou finge que tem, o que prefiro acreditar). Em momento algum eu disse que erros no Weld não existem e devem ser frutos de testes mal realizados por você. O que disse é que passar apuros em PRODUÇÃO é culpa sua por não testar direito o que utiliza.
Por exemplo, veja bem o link que você publicou sobre o Weld. O programador analisou o comportamento do CDI com os beans em seu desenvolvimento, rodou o profiler basico do Eclipse, bad smell detectado, jogou os @Inject no lixo e usou @EJB. Voi-la, 90% free comparado com o cenário anterior. O problema que você teve em produção, ele não teve.
Assim como ninguém nunca foi obrigado a utiliza EJB para usar JavaEE ( como já dizia o tio Rod ), ninguém é obrigado a usar CDI para usar JEE6. Se você não aprova a tecnologia ou suas implementações, simplesmente não use, jogue fora, alternativas a isso tem aos montes. Mas mantenha-se antenado, muitas vezes o problema não esta na tecnologia, como demonstrei no post anterior o Weld vai MUITO bem
|
|
|
|
Se você esta "desesperado" por conta disso, o seu cliente deve estar muito mais por enfrentar um problema que já não existe a um bom tempo. Primeiro porque no mesmo mês que este artigo foi publicado (novembro do ano passado), este assunto foi debatido na lista weld-dev e foi corrigido no trunk na mesma semana por Stuart Douglas "stuart.w.douglas@gmail.com". Não, não foi por conta de nenhuma conversa misteriosa sua no IRC com alguém, nenhum Jira que você abriu (já que você não fez isso) e nem foi algum patch que você enviou (já que você nunca submeteu algum). Talvez você conheça os dados de alguns builds de novembro, publicados na weld-dev por Pete e Stuart após o fix:
Em dezembro o próprio autor do artigo que você linkou, blogou novamente sobre os problemas de leak no Glassfish, deixando bem claro que já não existia nenhum problema com WELD:
http://hwellmann.blogspot.com/2010/12/update-on-memory-issues-in-glassfish.html
hwellmann.blogspot wrote:"Weld has improved a lot, and I can no longer see any suspicious memory usage related to Weld (...) I'm really happy to see that Weld has improved a lot, so I would no longer consider it as a no-go"
... é, desde ano passado o blogueiro já não parece mais "desesperado" como você diz.
Então calma rapaz, não precisa continuar desesperado, você está apenas atrasado meses com os updates da tecnologia que você utiliza (aliás a versão final do Weld 1.1.0 esta disponível desde Janeiro).
|
|
|
|
Rubem Azenha wrote:
Peraí... geralmente eu não concordo muito com o chun, mas memory leaks costumam dar em produção. Mesmo com testes e tudo mais, geralmente você identifica o memory leak depois de o sistema rodar várias horas e com muitos usuários em uma situação real e não simulada. Vai dizer que isso nunca aconteceu com você por que seus testes são perfeitos?
Já tive problemas de memory leaks em produção exatamente por causa que o plano de teste não foi bem escrito. Discordo que precisa de horas para detectar um memory leak, concodo que leva-se horas para detectar ONDE foi o memory leak. Geralmente os recursos que são exauridos por causa de um leak tem uma curva bem característica, então não precisa de horas para detectar que você tem um problema, só olhar os relatórios de sua ferramenta de profile ou teste de carga preferida.
Rubem Azenha wrote:
Então não é um software confiável, concorda? Independente de ser produto ou projeto (segundo a definição da Red Hat), lançar uma versão final de um software sem testar direito é complicado
Existe muita diferença entre produto e projeto. Produto é algo que você vende, que você fornece serviços como SLA de suporte, consultoria, algo que lhe gera receita. Pra você poder garantir um SLA por contrato você precisa garantir que o produto é certificado para as plataforma que seu cliente irá utilizar, como chipset do hardware, versões e fabricantes da JVM, sistemas operacionais, drivers de conexão com banco de dados homologados, versões de banco de dados, de servidores de aplicação e mais umas 500 variáveis. Quando você tem um produto, você é OBRIGADO a garantir (com risco de pesadas multas), que ele irá funcionar sobre todas estas variáveis e isso não é barato, envolve a contratação de equipe de QA dedicada, custos com plataformas de parceiros (IBM/ORACLE por exemplo) entre muitos outros fatores.
Um projeto que não é um produto, não gera receita (no momento). São realizados vários testes pelos "desenvolvedores" (que muitas vezes não são da red Hat), mas não se pode contar por exemplo que você terá um mainframe da IBM com sua máquina virtual rodando os testes de integração para verificar como será o comportamento do projeto neste ambiente. Provavelmente você terá a "comunidade" fazendo isso e contribuindo. Você não terá uma equipe de engenheiros focadas 24x7 para resolução de problemas gerados por nao terem sido realizados estes testes, terá os fóruns de discussão e os issue tracker da vida. O ponto possitivo é que você terá o que chamamos de "bleeding edge" da tecnologia, e deverá pagar o preço por ela.
PS: O WELD não é produto, é projeto (for now)
|
|
|
|
Ok prometo que será a ultima banana que te alimento:
1- Não falei que o leak tem haver com o glassfish, o que afirmo é que a "bomba" como você se refere ao WELD parece muito mais explosiva no Glassfish do que no JBoss6. Isso é um fato. Não me refiro a algum leak, o que afirmo é com base no que temos trabalhado referente ao Glassfish.
2- Sua experiência em testes não ocasionou o memory leak, só alguém com sérios problema de compreensão de texto entenderia isso. O ponto é que se você colocou em produção e só notou algum problema de memory leak depois, independente do framework ou servidor que você utiliza, significa que seu teste não foi suficiente. A comunidade de desenvolvedores que construiu o framework não possui um QA como deve ter um produto antes de entrar em produção, exatamente pq não é um produto. Se você é usuário de Software Livre, sabe que se você não tem um empresa por tras, a responsabilidade é inteiramente e exclusivamente SUA, não queira culpar a comunidade... foi você quem escolheu usar uma ferramenta nestas condições, arque com as consequencias. Se você não esta feliz com o WELD, use OpenWebbeans, se não esta feliz com nenhuma dos dois, não use nenhum dos dois ou espere que isso vire produto para culpar alguém e exigir seus direitos contratuais... você tem ESCOLHA
3- Não sou JBoss Fã Boy, sou JBoss funcionário, Engenheiro de Software da JBoss/Red Hat USA, contratado para trabalhar nas plataformas Hibernate/Seam e Drools-BRMS
Espero melhoras para o seu sistema em produção e ver contribuições suas para os enumeros problemas que você tem encontrado.
[]s
|
|
|
|
Talvez o problema seja com a sua escolha com "app servers" (tsc) e com sua inexperiência em testar uma aplicação antes de coloca-la em produção (conforme você mesmo descreveu).
O Weld é maravilhosamente open source, você achou o memory leak e o corrigiu, ótimo, seu cliente deve ter ficado feliz.
No mais deixa pra lá, não alimento conhecidos e manjados trolls aqui do GUJ como você "chun(?)"
|
|
|
|
chun wrote:Esse Weld tá fod...:/
Cada vez mais me preoculpo que o "motor" do CDI padrão é uma bomba.
Se preocupe menos e contribua mais:
https://issues.jboss.org/browse/WELD
|
|
|
|
O texto tem base e fundamento. O que eu fico puto é com colunistas e o modo de como eles entregam as manchetes, como:
"O Android pode morrer" - Isso sim é lamentável.
idgnow--
|
|
|
|
|
|