Seam 3.0.0 Versão Final

puxa quanta notícia legal, richfaces 4, seam 3

vou ter q tirar um diazinho pra curtir esses frameworks

Para quem usa JSF + JPA, este framework é “tudo de bom”.

Flavio Almeida:

Para quem usa JSF + JPA, este framework é “tudo de bom”.

Aliás, este é também um grande problema dele: ser voltado a JSF.

[]´s

Discordo,

Se a função dele é justamente trabalhar com JSF cumpre muito bem.
Agora se a tecnologia JSF é falha é OUTRA estória.

Ahhh, só pode ser primeiro de abril. :twisted:

eu me lembro que ano passado houve uma notícia de primeiro de abril dizendo que a fundação Apache havia comprado a fundação Eclipse, e que eles haviam trocado a logo do Eclipse rsrs

Melhor remenda para o JSFail.

luiz_renato:

Discordo,

Se a função dele é justamente trabalhar com JSF cumpre muito bem.
Agora se a tecnologia JSF é falha é OUTRA estória.

Luiz, eu não falei nada diferente do que você acabou de falar. Eu mesmo acho o JBoss Seam um produto excelente (uso sempre que sou obrigado a usar JSF =) ). O ponto é que, por ser voltado a JSF, o Seam tem um defeito. Seria muito melhor se, por exemplo, ele pudesse trabalhar com JSF E JSP, assim ele teria um leque muito maior de usuários. Além disso, o ponto é óbvio: JSF é uma tecnologia deficiente.

[]´s

asaudate, não me entenda mal, gosto sempre dos seus posts, mas há como esmiuçar a sua definição de deficiente? Ficou muito vago, quero saber, por curiosidade, quais os pontos que depreciam o uso da tecnologia JSF.

asaudate:

Luiz, eu não falei nada diferente do que você acabou de falar. Eu mesmo acho o JBoss Seam um produto excelente (uso sempre que sou obrigado a usar JSF =) ). O ponto é que, por ser voltado a JSF, o Seam tem um defeito. Seria muito melhor se, por exemplo, ele pudesse trabalhar com JSF E JSP, assim ele teria um leque muito maior de usuários. Além disso, o ponto é óbvio: JSF é uma tecnologia deficiente.
[]´s

O propósito do Seam sempre foi unir JSF ao JEE, pois a sun fez essas duas especificações como se uma não conhecesse a outra. Tornando o desenvolvimento uma dor de cabeça quando se desejava usar JSF/JEE(mais especificamente, EJBs).

Até por isso o nome “Seam”.

Pessoal, é bom lembrar que, apesar do foco principal ser JSF, nada impede de usá-lo com Wicket ou até mesmo GWT. Na própria documentação tem exemplos dessas e outras integrações.

Sem grilo asaudate !!

Boa informação ranophoenix !

[]'s

[2]

[2]

Do aspecto não funcional, tem a performance e capacidade. Um exemplo é um bug que foi reportado recentemente que dizia que uma sessão Ajax4JSF consumia 10 MB por cliente. (Não gostaria de imaginar um código desses indo para produção…). Além disso, pelo fato de cada página ficar extremamente carregada com javascript + html gerado pelo próprio JSF, as páginas podem levar muito tempo para serem produzidas e enviadas pela rede. O que faz de JSF uma carroça.

EDIT: ah, e acabei de lembrar, também - JSF complica a vida de quem quer usar um javascript próprio para manipulação de um componente qualquer. Ou seja, os componentes JSF que vêm com as bibliotecas são todos do tipo caixa-preta.

Do aspecto prático, tem o desenvolvimento de componentes: quem já tentou desenvolver um componente sabe que é super complicado ter que desenvolver um componente, porque é preciso editar vários arquivos de configuração, estender várias classes, etc. Sem contar que o desenvolvimento pra uma versão de JSF nem sempre vai se aplicar a uma próxima versão. Só pra exemplificar, o primeiro componente JSF que desenvolví foi um simples componente para controle de datas (o da biblioteca que a gente usava, na época, não era suportado por uma versão de browser que nós precisávamos). Foi um pesadelo de três dias.

Pra finalizar, tem aquele ciclo de vida dele. Completamente não prático, cada vez que fazemos uma requisição, ele precisa desencadear todo um processamento só por causa do ciclo de vida. E note que não é por ser component-based, já que outros frameworks orientados a componentes, como o Wicket, não precisam realizar todo esse processamento de ciclo de vida.

Então, resumindo: por esses motivos, JSF é um problema para o cliente, para o desenvolvedor e para o arquiteto.

[]´s

ranophoenix:

Pessoal, é bom lembrar que, apesar do foco principal ser JSF, nada impede de usá-lo com Wicket ou até mesmo GWT. Na própria documentação tem exemplos dessas e outras integrações.

Taí, dessa eu não sabia. Continua sendo válido o uso de JBoss EL com essas integrações?

[]´s

[2]

Do aspecto não funcional, tem a performance e capacidade. Um exemplo é um bug que foi reportado recentemente que dizia que uma sessão Ajax4JSF consumia 10 MB por cliente. (Não gostaria de imaginar um código desses indo para produção…). Além disso, pelo fato de cada página ficar extremamente carregada com javascript + html gerado pelo próprio JSF, as páginas podem levar muito tempo para serem produzidas e enviadas pela rede. O que faz de JSF uma carroça.

EDIT: ah, e acabei de lembrar, também - JSF complica a vida de quem quer usar um javascript próprio para manipulação de um componente qualquer. Ou seja, os componentes JSF que vêm com as bibliotecas são todos do tipo caixa-preta.

Do aspecto prático, tem o desenvolvimento de componentes: quem já tentou desenvolver um componente sabe que é super complicado ter que desenvolver um componente, porque é preciso editar vários arquivos de configuração, estender várias classes, etc. Sem contar que o desenvolvimento pra uma versão de JSF nem sempre vai se aplicar a uma próxima versão. Só pra exemplificar, o primeiro componente JSF que desenvolví foi um simples componente para controle de datas (o da biblioteca que a gente usava, na época, não era suportado por uma versão de browser que nós precisávamos). Foi um pesadelo de três dias.

Pra finalizar, tem aquele ciclo de vida dele. Completamente não prático, cada vez que fazemos uma requisição, ele precisa desencadear todo um processamento só por causa do ciclo de vida. E note que não é por ser component-based, já que outros frameworks orientados a componentes, como o Wicket, não precisam realizar todo esse processamento de ciclo de vida.

Então, resumindo: por esses motivos, JSF é um problema para o cliente, para o desenvolvedor e para o arquiteto.

[]´s

Seus comentários são perfeitamente válidos para o JSF 1.x. No JSF 2 muitas coisas foram melhoradas (a criação de componentes beira quase o trivial). Vale a pena dar uma conferida nas novidades. Segue um resumo:

http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/

asaudate:

ranophoenix:

Pessoal, é bom lembrar que, apesar do foco principal ser JSF, nada impede de usá-lo com Wicket ou até mesmo GWT. Na própria documentação tem exemplos dessas e outras integrações.

Taí, dessa eu não sabia. Continua sendo válido o uso de JBoss EL com essas integrações?

[]´s

Sim.

[2]

Do aspecto não funcional, tem a performance e capacidade. Um exemplo é um bug que foi reportado recentemente que dizia que uma sessão Ajax4JSF consumia 10 MB por cliente. (Não gostaria de imaginar um código desses indo para produção…). Além disso, pelo fato de cada página ficar extremamente carregada com javascript + html gerado pelo próprio JSF, as páginas podem levar muito tempo para serem produzidas e enviadas pela rede. O que faz de JSF uma carroça.

EDIT: ah, e acabei de lembrar, também - JSF complica a vida de quem quer usar um javascript próprio para manipulação de um componente qualquer. Ou seja, os componentes JSF que vêm com as bibliotecas são todos do tipo caixa-preta.

Do aspecto prático, tem o desenvolvimento de componentes: quem já tentou desenvolver um componente sabe que é super complicado ter que desenvolver um componente, porque é preciso editar vários arquivos de configuração, estender várias classes, etc. Sem contar que o desenvolvimento pra uma versão de JSF nem sempre vai se aplicar a uma próxima versão. Só pra exemplificar, o primeiro componente JSF que desenvolví foi um simples componente para controle de datas (o da biblioteca que a gente usava, na época, não era suportado por uma versão de browser que nós precisávamos). Foi um pesadelo de três dias.

Pra finalizar, tem aquele ciclo de vida dele. Completamente não prático, cada vez que fazemos uma requisição, ele precisa desencadear todo um processamento só por causa do ciclo de vida. E note que não é por ser component-based, já que outros frameworks orientados a componentes, como o Wicket, não precisam realizar todo esse processamento de ciclo de vida.

Então, resumindo: por esses motivos, JSF é um problema para o cliente, para o desenvolvedor e para o arquiteto.

[]´s

Seus comentários são perfeitamente válidos para o JSF 1.x. No JSF 2 muitas coisas foram melhoradas (a criação de componentes beira quase o trivial). Vale a pena dar uma conferida nas novidades. Segue um resumo:

http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/

Sinceramente? Tirando a parte de componentização, que parece um pouco mais simples mesmo, o resto me parece mais do mesmo. A impressão é que ele continua gerando um caminhão de código caixa-preta, e que a maior diferença é que o que antes a gente conseguia usando algumas bibliotecas (como salvar estado, ter ajax nativo, etc.) agora é parte da spec.

Bom, como eu disse, é só uma impressão (não conheço JSF 2). Quando eu tiver um tempinho, faço um benchmark e posto por aqui…

[]´s

Não costumo participar de floods ou alimentar bate bocas, mas confesso que é revoltante ver alguem condenar uma tecnologia por pura inexperiência.
O JSF assim como o Java é uma tecnologia aberta e a evolução dela depende de todos nós, seria um tanto estranho acreditar que o JSF foi criado por apenas UMA pessoa e que ela fosse uma “toupeira” a ponto de fazer um framework tão ruim a ponto de ter se tornado o framework padrão da especificação.
Apesar de achar errado, qualquer um que queira criticar alguma coisa, que pelo menos se mantenha atualizado sobre o assunto para não acabar fazendo papel de bobo.

Fábio

Fabio_Barboza:

Não costumo participar de floods ou alimentar bate bocas, mas confesso que é revoltante ver alguem condenar uma tecnologia por pura inexperiência.
O JSF assim como o Java é uma tecnologia aberta e a evolução dela depende de todos nós, seria um tanto estranho acreditar que o JSF foi criado por apenas UMA pessoa e que ela fosse uma “toupeira” a ponto de fazer um framework tão ruim a ponto de ter se tornado o framework padrão da especificação.
Apesar de achar errado, qualquer um que queira criticar alguma coisa, que pelo menos se mantenha atualizado sobre o assunto para não acabar fazendo papel de bobo.

Fábio

Oi Fabio, eu trabalhei com 2 projetos de grande porte com JSF 2. Li livros de capa a contra capa a respeito do JSF 2. E confesso que sofre e me frustei com JSF: http://guj.com.br/java/236788-crise-com-jsf/

Infelizmente, por mais que seja especificação, o problema do JSF (1 ou 2) está na sua filosofia Component-Based. Por mais que ela evolua, e fique boa, ao utilizá-la, sempre estaremos presos aos componentes . E como o asaudate disse, os componentes vem em uma caixa-preta. Ao usar JSF, não temos muito domínio de Html, Css e JS, faz uma sopa de mistura com Cliente e Server. Ficamos dependente de terceiros (Prime, Rich, Open e cia.), além de alguns bugs misteriosos e problemas de performance.

Quanto ao SEAM 3.0 boa notícia para quem insiste ou é obrigado usar JSF.

Concordo com o fábio, as vezes é mais fácil criticar algo que não conhecemos do que entender como as coisas realmente funcionam, procurar se interar a respeito das capacidades, caracteristicas e pontos fortes de determinada ferramenta ou tecnologia. Falhas todo software/framework possui, isso é fato, não existe software perfeito. Mas também vale lembrar que o JSF é especificação e não se tornou especificação so porque acharam o negócio bonito, porque encontraram muitas caracteristicas que podiam beneficiar e facilitar a vida de muita gente. E o Seam segue a mesma linha, foi a primeira implementação de referência para o que veio se tornar o CDI. Além de Wicket e Gwt também você pode usar flex se preferir ou até mesmo jsp puro. Vai do gosto do freguês. Se não quiser usar ejb também pode-se usar spring, vai do seu gosto e das suas necessidades como desenvolvedor em atender o seu cliente.

Lucas Emanuel:

Fabio_Barboza:

Não costumo participar de floods ou alimentar bate bocas, mas confesso que é revoltante ver alguem condenar uma tecnologia por pura inexperiência.
O JSF assim como o Java é uma tecnologia aberta e a evolução dela depende de todos nós, seria um tanto estranho acreditar que o JSF foi criado por apenas UMA pessoa e que ela fosse uma “toupeira” a ponto de fazer um framework tão ruim a ponto de ter se tornado o framework padrão da especificação.
Apesar de achar errado, qualquer um que queira criticar alguma coisa, que pelo menos se mantenha atualizado sobre o assunto para não acabar fazendo papel de bobo.

Fábio

Oi Fabio, eu trabalhei com 2 projetos de grande porte com JSF 2. Li livros de capa a contra capa a respeito do JSF 2. E confesso que sofre e me frustei com JSF: http://guj.com.br/java/236788-crise-com-jsf/

Infelizmente, por mais que seja especificação, o problema do JSF (1 ou 2) está na sua filosofia Component-Based. Por mais que ela evolua, e fique boa, ao utilizá-la, sempre estaremos presos aos componentes . E como o asaudate disse, os componentes vem em uma caixa-preta. Ao usar JSF, não temos muito domínio de Html, Css e JS, faz uma sopa de mistura com Cliente e Server. Ficamos dependente de terceiros (Prime, Rich, Open e cia.), além de alguns bugs misteriosos e problemas de performance.

Quanto ao SEAM 3.0 boa notícia para quem insiste ou é obrigado usar JSF.

Problemas com alguma lignuagem/framweork são muito relativos.
Quando eu comecei com o JSF/Richfaces também tive muitos problemas, pensei até em desistir e correr para outro framework, concordo que tinham alguns problemas mas eram contornáveis.
Hoje eu posso afirmar que conheço muito bem a tecnologia e que não trocaria por nenhuma outra. No MEU ponto de vista, trabalhar a base de componentes é o ideal (Pode ser que daqui a algum tempo mude).
Eu pessoalmente não gosto de Struts e GWT, tive más experiências com ambos principalmente na hora de dar manutenção em código alheio, mas não acho que eles sejam frameworks ruins.
E mais, MUITAS da features que eram do Seam foram incoporadas ao JSF 2 / EE 6. Exs: Contexto de conversação, declaração de managedbeans por annotation e o CDI.
Resumindo, é tudo uma questão de gosto, o que eu não acho legal e ficar sujando a imagem de outras tecnologias.

Fábio

O Prime, Rich e Open Faces são tão “caixa-preta” quanto o jquery, yui, etc. Não vejo nenhum problema em utilizar “caixa-preta” desde que ela cumpra o que promete. Antes de começar qualquer projeto, em qualquer tecnologia, sempre temos que homologar os componentes que serão utilizados. E em caso de problemas, nada impede de abrirmos a “caixa-preta” e corrigirmos eventuais problemas e colaborar com o crescimento da tecnologia.

Acredito que JSF resolve bem o que se propõe. É para todos casos? Resolve todos os problemas? Óbvio que não, mas é uma excelente opção para certos cenários.

Na minha opinião, o conceito de “caixa-preta” é relativo. Tem que ter muito bom senso para pesar bem: controle do código, produtividade, utilização de bibliotecas de terceiros, etc. No final, sempre a melhor resposta é: depende. Cada caso é um caso.

“asaudate”:

Do aspecto não funcional, tem a performance e capacidade. Um exemplo é um bug que foi reportado recentemente que dizia que uma sessão Ajax4JSF consumia 10 MB por cliente. (Não gostaria de imaginar um código desses indo para produção…). Além disso, pelo fato de cada página ficar extremamente carregada com javascript + html gerado pelo próprio JSF, as páginas podem levar muito tempo para serem produzidas e enviadas pela rede. O que faz de JSF uma carroça.

EDIT: ah, e acabei de lembrar, também - JSF complica a vida de quem quer usar um javascript próprio para manipulação de um componente qualquer. Ou seja, os componentes JSF que vêm com as bibliotecas são todos do tipo caixa-preta.

Do aspecto prático, tem o desenvolvimento de componentes: quem já tentou desenvolver um componente sabe que é super complicado ter que desenvolver um componente, porque é preciso editar vários arquivos de configuração, estender várias classes, etc. Sem contar que o desenvolvimento pra uma versão de JSF nem sempre vai se aplicar a uma próxima versão. Só pra exemplificar, o primeiro componente JSF que desenvolví foi um simples componente para controle de datas (o da biblioteca que a gente usava, na época, não era suportado por uma versão de browser que nós precisávamos). Foi um pesadelo de três dias.

Pra finalizar, tem aquele ciclo de vida dele. Completamente não prático, cada vez que fazemos uma requisição, ele precisa desencadear todo um processamento só por causa do ciclo de vida. E note que não é por ser component-based, já que outros frameworks orientados a componentes, como o Wicket, não precisam realizar todo esse processamento de ciclo de vida.

Então, resumindo: por esses motivos, JSF é um problema para o cliente, para o desenvolvedor e para o arquiteto.

De fato, seus pontos condiz com a realidade do framework, e sempre soube disso.

Não é negável que ele é pesado, talvez para aplicações com milhares de acessos ao mesmo tempo, ele possa se tornar uma tecnologia inviável, pois gera uma quantidade absurda de código para gerenciar seus recursos de componentização.

É o preço que pagamos por ter componentes poderosos sendo incorporados facilmente nas aplicações. Nos abstrae de muita lógica, inclusive, muitos css e javascripts (que pode ser very boring), mas é pesado, ineficiente para sites, bom para sistemas e com ciclo de vida confuso.

o povo ta misturando as coisas… vocês chamam de pesado isso e aquilo, javascript aos quilos por que o prime isso o richfaces aquilo, mas vocês esquecem que essas bibliotecas não são parte da especificação, são algo que alguém(uma empresa) criou para facilitar a vida dos programadores(que acham bonitinho e vão usando de qualquer jeito).
JSF pode ser usado com componentes que você mesmo pode criar, vai de você criar um componente bom ou não.

** Edited

feito em JSF, tem muito acesso, é o parceiro do banco do brasil e renderiza rápido a dar com o pau, ou seja, existe prova que algo bem feito fica bom.
pegue um livro, estude, e aprenda a utilizar a framework/tecnologia de maneira correta, não importa qual seja.
sem mais.

rodriguezrps:

o povo ta misturando as coisas… vocês chamam de pesado isso e aquilo, javascript aos quilos por que o prime isso o richfaces aquilo, mas vocês esquecem que essas bibliotecas não são parte da especificação, são algo que alguém(uma empresa) criou para facilitar a vida dos programadores(que acham bonitinho e vão usando de qualquer jeito).
JSF pode ser usado com componentes que você mesmo pode criar, vai de você criar um componente bom ou não.

** Edited

feito em JSF, tem muito acesso, é o parceiro do banco do brasil e renderiza rápido a dar com o pau, ou seja, existe prova que algo bem feito fica bom.
pegue um livro, estude, e aprenda a utilizar a framework/tecnologia de maneira correta, não importa qual seja.
sem mais.

Aham. 162 kb só de texto na primeira página (note que eu fiz a contagem só do texto, ou seja, com recursos importados, como CSS/imagens/javascript fica ainda mais pesado). Multiplique 162 kb, por, digamos, 100 usuários em uma hora (estou chutando até baixo). Isso dá 16 MB de transferência em uma hora. Considere o dia inteiro (como eu chutei baixo pra uma hora, acho justo desconsiderar picos de acesso, para efeito de cálculo). Dá 390 MB. De texto. E você vem me falar que foi bem feito?

Pegue então a latência de transferência pros roteadores, o custo de fazer o processamento disso no firewall, o custo do processamento disso no web server e no application server e… ixe, eu acho melhor migrar pra JSP ou outros frameworks que não precisam disso (como o Play, Ruby/Rails, Grails…).

Note que eu não falei, em momento algum da minha explicação, que usei porque era bonitinho. Também acho que não demonstrei inexperiência com o framework (exceto na parte em que disse que não conheço JSF 2. Eu procuro ser honesto na minha visão sobre as coisas, sabe?).

De qualquer maneira, muitas pessoas não gostam de JSF. E isso tem motivos. E não pensem vocês que só porque uma especificação é feita que a gente deve abraçar cegamente (afinal de contas, duvido que alguém aqui tenha argumentos pra defender, por exemplo, EJB 1 ou 2).

Meus caros, peço a vocês que tenham visão crítica das coisas. Não somente sair por aí abraçando porque alguém falou que é bom (ou que é ruim - ou seja, não vou tentar convencê-los do contrário; espero somente que a minha visão seja respeitada, assim como eu respeito a de vocês). Corram atrás. Procurem checar se o que eu falei é verdade. Eu disse que não conhecço JSF 2, vocês dissem que conhecem. OK, vocês têm benchmarks para mostrar? O rodriguezrps disse que o comprafacil é usado por muitos usuários. Quantos são “muitos usuários” ? Tem picos de acesso? Quantos servidores são usados para atender essa demanda?

Peço a vocês, novamente, que não tomem tudo como verdade, mas sim que analisem os fatos.

Cordialmente,

Um artigo que acho bastante relevante nessas discussões sobre perfomance, benchmarks, desempenho, etc:

http://engineroom.mixx.com/2008/08/10/ruby-on-rails-vs-java-vs-c-vs-assembler/

Concordo com o que asaudate disse, evitem acreditar em qualquer coisa, seja de quem for e, principalmente, evitem os preconceitos. Tenham bom senso acima de tudo, conheçam o máximo (e quem sabe ao máximo) o maior número de tecnologias possível e escolham a mais adequada para o cenário em questão.

Abs,

ranophoenix:

Um artigo que acho bastante relevante nessas discussões sobre perfomance, benchmarks, desempenho, etc:

http://engineroom.mixx.com/2008/08/10/ruby-on-rails-vs-java-vs-c-vs-assembler/

Concordo com o que asaudate disse, evitem acreditar em qualquer coisa, seja de quem for e, principalmente, evitem os preconceitos. Tenham bom senso acima de tudo, conheçam o máximo (e quem sabe ao máximo) o maior número de tecnologias possível e escolham a mais adequada para o cenário em questão.

Abs,

Aliás, por falar em benchmarks, fiz um testezinho rápido em cima do comprafacil.com.br. Simulei cinco usuários simultâneos, fazendo requests pra página inicial, durante um minuto. O tempo médio de resposta foi 733,32 ms, com 32.471.239 bytes transferidos no total (~ 32 MB), sendo 540 KB de transferência média, por segundo. Além disso, o tempo máximo de resposta 3472 ms (3 segundos e meio).

Vocês não acham que cinco usuários simultâneos, durante um minuto só, é um valor para testes muito baixo para ter valores de resposta tão altos?

asaudate:

ranophoenix:

Um artigo que acho bastante relevante nessas discussões sobre perfomance, benchmarks, desempenho, etc:

http://engineroom.mixx.com/2008/08/10/ruby-on-rails-vs-java-vs-c-vs-assembler/

Concordo com o que asaudate disse, evitem acreditar em qualquer coisa, seja de quem for e, principalmente, evitem os preconceitos. Tenham bom senso acima de tudo, conheçam o máximo (e quem sabe ao máximo) o maior número de tecnologias possível e escolham a mais adequada para o cenário em questão.

Abs,

Aliás, por falar em benchmarks, fiz um testezinho rápido em cima do comprafacil.com.br. Simulei cinco usuários simultâneos, fazendo requests pra página inicial, durante um minuto. O tempo médio de resposta foi 733,32 ms, com 32.471.239 bytes transferidos no total (~ 32 MB), sendo 540 KB de transferência média, por segundo. Além disso, o tempo máximo de resposta 3472 ms (3 segundos e meio).

Vocês não acham que cinco usuários simultâneos, durante um minuto só, é um valor para testes muito baixo para ter valores de resposta tão altos?

Realmente, mas acho que em relação ao compra fácil pouco tem haver com o fato de ser JSF. Com o Firebug percebe-se que os maiores “vilões” são os SWFs (Flash).

Triste é a plataforma de software que tem em um framework como o JBoss Seam (“costura” em inglês, sabe, tipo aquelas das fantasias de São João…) como sua referência de alta tecnologia e do melhor que há para seu desenvolvimento.

Triste é o fórum de discussão da web em que usuários “não querem alimentar bate bocas” mas rebaixam o argumento dos outros classificando-os como “falta de experiência”, e que seus argumentadores estão “fazendo papel de bobo”.

asaudate:

Aliás, por falar em benchmarks, fiz um testezinho rápido em cima do comprafacil.com.br. Simulei cinco usuários simultâneos, fazendo requests pra página inicial, durante um minuto. O tempo médio de resposta foi 733,32 ms, com 32.471.239 bytes transferidos no total (~ 32 MB), sendo 540 KB de transferência média, por segundo. Além disso, o tempo máximo de resposta 3472 ms (3 segundos e meio).

Vocês não acham que cinco usuários simultâneos, durante um minuto só, é um valor para testes muito baixo para ter valores de resposta tão altos?

Ta, estou chegando agora, não disse nada sobre nenhum, mas gostaria de ver o seguinte, pegue outro site com ± a mesma carga e cheio de parafernalhas que o comprafacil, porem feito em outra coisa, sei la: rails, vraptor, struts, aspx, e faça este mesmo teste que voce fez, bora ver o q da!
Sei la? que sites temos ae? Alguem sabe em q é feito shoptime, americanas, submarino, polishop, magazineluiza, etc, etc. Bora testar e ver os resultados. Testar apenas um, olhar os valores e achar altos, puramente por achar, sem comparar com outros, acho sem noção! E não é pra comparar com “meu sitezinho feito em vRapror”, nao, vamos comparar estes grandes portais!!

E só pra constar, sem levar em conta que seja feito em JSF ou action based, eu acho sim o compra facil bem acessado, inclusive ele tem programas com empresas e tals.

Por que as pessoas ficam ofendidas quando se fala mal do JSF? Parece até que está fazendo uma coisa errada. Eu vou além, sugiro que somente as pessoas que gostem desta tecnologia tenham o direito de trabalhar. Já o resto, da noite pro dia virou um bando de bundão, não acompanhou a evolução “natural” do desenvolvimento de sistemas e, por isso mesmo, por serem tratados como estagnados deveriam mudar de área.

De fato essa gororoba Seam é o que torna JSF viável. Propositalmente, igual acontece com a placa-mae e o processador, um completa o outro. JSF é puro marketing, sem qualquer novidade, a velha história de criar dificuldade para vender facilidade. Foi o jeito que a Head Ret encontrou para entrar no mercado de desenvolvimento de sistemas. Como seria competitivo se continuasse com JSP? Spring e struts 2.

A “facilidade”, “flexibilidade” e “agilidade” se resumem a uma tela de 3 a 4 controles, e termina por ai, o resto é workaround. JSF é uma mistura de egoísmo e arrogância: Somente Nick Belaevski é sábio o bastante para utilizar JavaScript na camada de apresentação, nenhum outro programador é capaz de utilizar esta linguagem de forma responsável.

A criação de novos componentes JSF deveria vir com letras grandes “NÃO TENTE FAZER ISSO EM CASA”. De fato, a criação de um componente envolve uma babozeira tão absurda que desencoraja qualquer tentativa.

É a maldição dessas revistinhas JAVA. Se um dia publicarem que esfregar cocô na careca faz nascer cabelo, todo mundo vai querer usar.

Maluco, eu ri litros agora com essa!!!

Alguém sabe se em um projeto usando: JSF 2 + Spring + Hibernate + Primefaces, com o spring resolvendo as ELs e injetando os services nos ManagedBean, o SEAM teria alguma função?

Da mesma forma que muitos ficam ofendidos quando alguém fala que gosta ou que vê vantagens. Nada mais é que briga de egos, se a pessoa prefere um framework, quer se justificar depreciando os outros ou quem prefere outro, não aceitam opinião diferente. Não sei se é insegurança por não conseguir trabalhar bem de outra forma da que está acostumado, se é pra dar uma de esperto ou por briga de egos, mas isso é muito comum por aqui.

Particularmente, nunca vi todos esses problemas com JSF, minhas páginas nunca ficaram “extremamente” grandes e nunca achei a criação de componentes tão complexa assim como o pessoal postou, trabalhar com javascript nele tem o mesmo trabalho do que com outros frameworks. E está cheio de empresas que ganham uma produtividade absurda com a componentização de seus sistemas.

Aliás, até fico admirado do tanto de gente que trabalha um bom tempo com Java e acha difícil criar componentes com JSF ou vê isso como uma “caixa preta”.

Concordo em gênero, número e grau com o Marcos. E, por incrível que pareça, com o JEE 6 a adoção do Seam é até questionável. Perguntas que chovem nas listas do seam hoje são sempre assim: “Seam or JEE 6 only?”. Boa parte das idéias do Seam 2 foram incorporadas ao JEE 6. O Seam 3 só constrói alguns módulos “periféricos” totalmente opcionais, por isso que não acredito que ele vai ter o mesmo boom que teve no JEE 5. Boa parte dos problemas do JSF 1.x era devido a integração com JSP, por isso que a criação de componentes era relativamente trabalhosa (não digo difícil). O JSF 2 utiliza facelets e fazer componentes ficou trivial, qualquer desenvolvedor que trabalhe com xhtml faz um rapidinho. Praticamente, grosseiramente falando, está bem semelhante a desenvolver taglibs no JSP.

Aconselho para quem quiser aprender mais sobre o JSF 2, sem preconceitos, fazer a leitura desse material:

Core JavaServer Faces (3rd Edition)

Abs,

ranophoenix:

asaudate:

ranophoenix:

Um artigo que acho bastante relevante nessas discussões sobre perfomance, benchmarks, desempenho, etc:

http://engineroom.mixx.com/2008/08/10/ruby-on-rails-vs-java-vs-c-vs-assembler/

Concordo com o que asaudate disse, evitem acreditar em qualquer coisa, seja de quem for e, principalmente, evitem os preconceitos. Tenham bom senso acima de tudo, conheçam o máximo (e quem sabe ao máximo) o maior número de tecnologias possível e escolham a mais adequada para o cenário em questão.

Abs,

Aliás, por falar em benchmarks, fiz um testezinho rápido em cima do comprafacil.com.br. Simulei cinco usuários simultâneos, fazendo requests pra página inicial, durante um minuto. O tempo médio de resposta foi 733,32 ms, com 32.471.239 bytes transferidos no total (~ 32 MB), sendo 540 KB de transferência média, por segundo. Além disso, o tempo máximo de resposta 3472 ms (3 segundos e meio).

Vocês não acham que cinco usuários simultâneos, durante um minuto só, é um valor para testes muito baixo para ter valores de resposta tão altos?

Realmente, mas acho que em relação ao compra fácil pouco tem haver com o fato de ser JSF. Com o Firebug percebe-se que os maiores “vilões” são os SWFs (Flash).

O teste que eu fiz puxava somente o texto. Lembra o que eu falei, só de texto são 160 KB? Não precisei fazer o teste puxar tudo pra ter esses tempos absurdos.

[]´s

Da mesma forma que muitos ficam ofendidos quando alguém fala que gosta ou que vê vantagens. Nada mais é que briga de egos, se a pessoa prefere um framework, quer se justificar depreciando os outros ou quem prefere outro, não aceitam opinião diferente. Não sei se é insegurança por não conseguir trabalhar bem de outra forma da que está acostumado, se é pra dar uma de esperto ou por briga de egos, mas isso é muito comum por aqui.

Particularmente, nunca vi todos esses problemas com JSF, minhas páginas nunca ficaram “extremamente” grandes e nunca achei a criação de componentes tão complexa assim como o pessoal postou, trabalhar com javascript nele tem o mesmo trabalho do que com outros frameworks. E está cheio de empresas que ganham uma produtividade absurda com a componentização de seus sistemas.

Aliás, até fico admirado do tanto de gente que trabalha um bom tempo com Java e acha difícil criar componentes com JSF ou vê isso como uma “caixa preta”.

Concordo contigo, Marcos. A idéia de mostrar o benchmark do comprafacil foi feita porque algumas pessoas, na hora de defender uma argumentação, falam que é porque outras não tem “experiência suficiente” para fazer uma colocação. Como falaram pra mim que o tal do comprafacil é um exemplo bem feito, fiz o benchmark (e, repito, somente puxando o texto) para demonstrar que o que é bem feito do ponto de vista do usuário pode ser um pesadelo pro administrador do sistema, por exemplo (tenho certeza que o tal do comprafacil está hospedado em uma farm gigante!).

Mas não tenho nenhum problema com quem trabalha com isso. Oras, eu mesmo trabalho mais com JSF do que com outras tecnologias. É uma questão de gosto.

A quem falou de fazer outros benchmarks, aviso que tentei fazer com o UOL. Só que a minha ferramenta de testes tem um drawback de só fazer POST (o comprafacil devolve a página inteira mesmo quando a requisição é POST… ). Ficaria feliz de aplicar o mesmo teste em sites feitos com outras tecnologias, só pra ter uma base de comparação.

[]´s

Eu reconheço o lado positivo e negativo da tecnologia JSF. Nunca achei que ele fosse resolver todos os problemas web, e de fato, não resolve. Também não concordo com o ponto de vista de ele ser sempre uma tecnologia mal vista, onde não serve nem para sistemas quanto sites.

Acredito que o maior mérito seja o poder de permitir várias implementações com vários recursos já on built, porém, como eu disse antes, isso tem um preço. Por mais que se crie novas implementações não há como fugir do core do JSF, a especificação deve ser seguida, e queira ou não, os componentes ainda se tornarão pesados.

Eu mesmo, fui desenvoler um projeto para minha mulher para ela melhor organizar seus estudos, já que o concurso que ela está estudando demanda de muitos assuntos, muito tempo e muitas matérias a serem estudadas.

Resolvi criar um sistema, e acabei optando por RichFaces em detrimento ao Play Framework pelo simples fato de eu saber mexer com jQuery e não querer perder muito tempo em css e design. E como é um projeto pessoal, onde dificilmente irá sair do nosso escopo caseiro, então preferi usar essa mesma tecnologia que já conhecia e facilmente consigo adaptar as coisas nela.

Obviamente que sei de suas limitações, sei que JSF é tosco se você quiser forcá-lo a usar um outro padrão de layout, sei que ele é chato de trabalhar com outros frameworks de JavaScript, sei que ele é pesado, mas está me atendendo muito bem para um projeto pessoal.

Mas acredito que jamais iria querer usá-lo num projeto grande que fosse um site, as suas desvantagens iriam pessar muito mais, e poderia tornar o projeto inviável.

Site exige leveza, fácil customização, processamento rápido e objetivo, e isso, o JSF não consegue atender de forma eficiente, e na verdade, esse nunca foi o objetivo dele.

Não quero aqui tirar o mérito de nenhum framework, acho que o próprio JSF (ainda mais na versão 2) tem suas vantagens, a questão é quando saber usá-lo. Não se pode querer que ele atenda a tudo e a qualquer tipo de projeto e especificação, é saber conhecer para que tipo de situação ele demanda e trabalha melhor.

Acho que só o Spring já tá de bom tamanho.

Legal. E tem um módulo Wicket tbm

Meus 2 centavos :). A discussão sobre JSF é bem válida, só não concordo com os argumentos: gera html porco, css não é seu, componentes de caixa preta e coisas do genero. Se não quer isso, não usa JSF, porque a idéia dele passa por tentar fazer você não se preocupar com esses detalhes. Só se preocupa com html,css e js otimizado quem tá fazendo um website e se você tá fazendo isso com JSF tá indo pelo caminho errado. Quem tá montando webapp em geral não vai se preocupar tanto se
página demorou um pouco mais para responder ou não. Não é esse o foco… Pelo menos é o que eu acho.

Voce tem muita razão.

Negativo.

Eu trabalho com Sistema no setor de saúde. São muitos (muitos mesmos) hospitais e clínicas acessando ao mesmo tempo, 24X7, num ambiente clusterizado. Existem filas para atender os pacientes.
Saúde no Brasil já é um caos. Imagine se a fila não anda por causa de travamento ou lerdesa no sistema. Cada segundo ganho é crucial. Fora que a manutenão num sistema deste porte precisa ser rápida, coisa que JSF nao oferece, porque faz uma sopa de merda misturando Client-Side com Server-Side.

Essa idéia de não se preocupar com Front-End está matando muitas WebApps, Front-end está muito relacionado com performance, veja o livro: High Performance Web Sites Essential Knowledge for Front-End Engineers.

Enfim, não optamos por JSF e foi a escolha mais feliz.

alots_ssa:

Meus 2 centavos :). A discussão sobre JSF é bem válida, só não concordo com os argumentos: gera html porco, css não é seu, componentes de caixa preta e coisas do genero. Se não quer isso, não usa JSF, porque a idéia dele passa por tentar fazer você não se preocupar com esses detalhes. Só se preocupa com html,css e js otimizado quem tá fazendo um website e se você tá fazendo isso com JSF tá indo pelo caminho errado. Quem tá montando webapp em geral não vai se preocupar tanto se
página demorou um pouco mais para responder ou não. Não é esse o foco… Pelo menos é o que eu acho.

Entao… discordo. Preocupação com performance e algo que, se não e uma preocupação de todo desenvolvedor, deveria ser. Isso porque você não quer que os usuários do seu sistema migrem pro sistema do seu concorrente simplesmente porque o seu e lento (e isso acontece bastante).

Acho que só o Spring já tá de bom tamanho.

Entendi…
Quando vi o JSF e o suporte que o Spring tem para ele, achei bem legal… Mas daí vi o Seam que a principio para JSF 1.x podia usar o tal ELResolver dele que aceita parametros sobre métodos…
Mas agora com JSF 2 com tudo que possui, não via no que realmente ele podia se encaixar…
E depois de seu post, me gerou menos dúvidas ainda…

Esse Weld tá fod…

Cada vez mais me preoculpo que o “motor” do CDI padrão é uma bomba.

chun:

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

Alessandro Lazarotti:

chun:

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

Respostinha padrão do “fã boy” da Jboss…

Quem botou o GF 3.0 com a BOMBA do WELD 1.0 em produção sabe BEM do que eu estou falando…

ps: se voce buscar nos JIRAS do WELD vai perceber o meu dedo por lá… em muitas questoes , inclusive no IRC… varias tardes para convencer o Peter de que o Weld tinha problemas de leak e de performance… , ele agendou para MESES depois a correção… legal né ?

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(?)”

Alessandro Lazarotti:

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(?)”

Hehehe… Leak do Weld tem a ver com “app server” ? Por favor… é para acabar hein ?

Maravilhosamente OpenSource ? Acho que vc REALMENTE nunca botou algo serio em cima do WELD 1.0…

Essa desculpinha de “o codigo tá lá , baixa e arruma” que fod… o Software Livre…

Quanto ao adjetivo , obrigado

O mais legal de tudo é que a minha “experiencia em testes” ocasionou leaks no codigo do WELD… :shock: esse é o meu “fã boy” preferido !!!

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

Alessandro Lazarotti:

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

1. Curioso né ? Tudo que é da JBoss funciona direito só o JBoss AS , muito curioso… MAIS curioso ainda é estes leaks terem sido descritos desde a versão ALPHA do 1.0 e continuarem lá na 1.0 final , INCLUSIVE dentro do JBoss…

2. A “Comunidade” é a JBoss , é um produto DELA e não da “Comunidade” , tanto que o peter disse “que nao podia fazer nada , pois todos desenvolvedores do projeto estavam alocados em outras coisas”. Uma coisa você tem razão… posso escolher … escolher entre “Um implementação sem nenhuma responsabilidade por parte da JBoss” e outra que é caduca… realmente eu tenho a opção.

3. E fã boy.

Obrigado

Logo que Peter largar mão de ficar enrolando e publicar meus pacthes a coisa talvez mude

Talvez isso seja um reflexo do “maravilhosamente open source” né ? :shock:

chun:

Obrigado

Logo que Peter largar mão de ficar enrolando e publicar meus pacthes a coisa talvez mude

Talvez isso seja um reflexo do “maravilhosamente open source” né ? :shock:

Estranho chun, por curiosidade eu olhei o Jira da JBoss e só achei um caso que você abriu e não tinha nenhuma submissão de patch nele.

https://issues.jboss.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=reporter+%3D+dyegocarmo

rimolive:

chun:

Obrigado

Logo que Peter largar mão de ficar enrolando e publicar meus pacthes a coisa talvez mude

Talvez isso seja um reflexo do “maravilhosamente open source” né ? :shock:

Estranho chun, por curiosidade eu olhei o Jira da JBoss e só achei um caso que você abriu e não tinha nenhuma submissão de patch nele.

https://issues.jboss.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=reporter+%3D+dyegocarmo

Este foi o que ele admitiu ser um problema , o resto ficou tudo via IRC.

Depois que ele me deu um prazo de 6 meses a 1 ano para resolver eu simplesmente larguei mão.

Vo fazer o que ? Essa é essa vida do “maravilhosamente open source”

Então significa que você passou todos os seus problema com o WELD para o Pete através do IRC e também submeteu seus patches pra ele desta forma? Meio estranho isso não? Será que talvez você não esteja sabendo reportar seus problema com o open source de forma correta?

:evil:

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?

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.

Rubem Azenha:

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?

Rubem Azenha:

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

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)

rimolive:

Então significa que você passou todos os seus problema com o WELD para o Pete através do IRC e também submeteu seus patches pra ele desta forma? Meio estranho isso não? Será que talvez você não esteja sabendo reportar seus problema com o open source de forma correta?

:evil:

Uso a freenode sempre que possivel , eh mais rapido e pratico , quando tive problemas com o glassfish tmb foi lah que procurei ajuda , somente nao tendo retorno eu abri algumas pendencias…

Eh o meu modo de cooperar , se voce tem alguma questao eh soh perguntar para o PETer sobre o nickname chun. (quem sabe ele aina se lembre)

O relato abaixo descreve o meu desespero com o o WELD…

Mais um cara que segundo o funcionario da JBoss “nao sabe testar direito”.

Vai ver que eh outro troll neh ? :shock:

chun:

O relato abaixo descreve o meu desespero com o o WELD…

Mais um cara que segundo o funcionario da JBoss “nao sabe testar direito”.

[]'s

O POST nao eh meu…

mas descreve exatamente o que passei…

Ahhh , tem mais um cara que nao sabe testar tmb:

http://qants.wordpress.com/category/glassfish/weld/

Esses inexperientes… :roll:

chun:

O relato abaixo descreve o meu desespero com o o WELD…

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 "[email removido]". 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:

Startup Time (Seconds)
Beans 	1.0.1-Final 	1.1.0.Beta1 	Latest

500           4 	        4 	          2.1
1000 	      8 	        7 	            3
5000 	    140 	       89 	          8.5
10000 	    600+ 	      396 	           14

Memory Usage (Mb)
Beans 	1.0.1-Final 	1.1.0.Beta1 	Latest

500 	    42 	            27 	           10
1000 	    82 	            53 	           19
5000 	   403 	           255 	           87
10000 	  ~800 	           507 	          172

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:

… é, 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).

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

Alessandro Lazarotti:

chun:

O relato abaixo descreve o meu desespero com o o WELD…

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 "[email removido]". 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:

Startup Time (Seconds)
Beans 	1.0.1-Final 	1.1.0.Beta1 	Latest

500           4 	        4 	          2.1
1000 	      8 	        7 	            3
5000 	    140 	       89 	          8.5
10000 	    600+ 	      396 	           14

Memory Usage (Mb)
Beans 	1.0.1-Final 	1.1.0.Beta1 	Latest

500 	    42 	            27 	           10
1000 	    82 	            53 	           19
5000 	   403 	           255 	           87
10000 	  ~800 	           507 	          172

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:

… é, 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).

Voce leu o que escrevi ? PASSEI e não estou PASSANDO com problemas de leak no WELD… (lembrando que o GF 3.1 saiu a BEM POUCO tempo)

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.

Acorda para a vida.

ps: Ué , deixei de ser troll ?
ps2: Para quem é tão especialista em testes usar uma versão BETA com mais de 40 correcoes adicionais está bem OUSADO não ? :shock:

Alterações/Correções no Beta2 : 42
Alterações/Correções no CR1 : 51
Alterações/Correções no CR2 : 10
Alterações/Correções no CR3 : 1
Alterações/Correções no CR4 : 8
Alterações/Correções no Final : 4

E Se voce ler na pagina do Seam3 tem MAIS COISA corrigida que deve ser pego do Snapshot para que o mesmo funcione corretamente. A Vangatem que agora PODEMOS atualizar com a SNAPSHOT , coisa que antes NAO ERA POSSIVEL

Alessandro Lazarotti:

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

Essa desculpisse aguda vindo de funcionários da propria JBoss não é uma exclusividade sua. Voces devem ter um curso de como deturpar as informações…

Ser responsavel por uma R.I. é algo realmente importante… ainda mais quando não existe outra implementação certificada

Voce acha realmente que eu uso o WELD para ficar colocando @Inject ? Quando voce ler direito a spec do CDI vai perceber que ele faz bem mais do uma simples injeção de dependencias. O seu “Voi-la” é o exemplo que me faz crer que no software livre a “metralhadora de desculpas” está sempre ligada.

Para variar você está fazendo papel de fã boy para justificar problemas injustificaveis e que levaram mais de 6 MESES , 6 MESES para ter uma solução definitiva… um problema DESTA natureza levando mais de 6 MESES para ter seu codigo disponibilizado em uma versão estável para outros APP SERVERS que não fossem o PROPRIO JBoss AS… Acho melhor voce conversar com o peter e ele vai te contar que ele reescreveu bastante coisa antes de lançar algo USAVEL, o WELD 1.1.0 ficou USAVEL MUITO TEMPO DEPOIS da correção dos leaks.

Acorda para a vida e para de tapar o sol com a peneira.

ps: Não esqueça de ler a minha assinatura

Ué, até agora, você estava “desesperado” com o Weld, falando que ele é uma “bomba”, etc :twisted:

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.

De acordo com todo o pessoal do GUJ que conheço… continua sendo

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.

Ué, até agora, você estava “desesperado” com o Weld, falando que ele é uma “bomba”, etc :twisted:

Continuo achando ele uma bomba , e sim , ESTIVE desesperado.
Leia a parte que escrevo sobre o relato não ser o meu

Ehehe… legal que já passei de troll para “mau testador” , depois “irresponsavel por nao atualizar” e agora me encontro na posição de “ingenuo”, Good ! :shock:

Bom , BOMBA continuo achando , desesperado não mais 8)

Mas a sua “ingenuidade” em achar que vou sair botando versões betas em sistemas em produção , essa ainda não entendi Só uma pessoa desesperada faria isso não ? :lol: Quem sabe uma pessoa OUSADA !!! (ainda mais quando não posso atualizar devido a um “detalhe” alterado na parte da SPI do Weld com o Glassfish :roll: )

Curiosamente agora usar coisas não testadas é ser ousado…

Então todos que utilizam JavaEE 6 … considerem-se OUSADOS …

Poderia ser slogan do WELD…

“Vamos OUSAR Hoje ?”

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.

Alessandro Lazarotti:

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.

Argumentos ? Como disse no PRIMEIRO POST… continuo achando uma BOMBA…

Antes mais do que hoje, os benchmarks postados justificam o que eu disse , mas como você esta “tentando” deturpar o que eu digo com afirmações sem conteudo, fazendo acreditar que são coisas de ANOS PASSADOS, vou fazer o que ? :roll:

A discussão iniciou com a sua atitude de fã boy em justificar coisas injustificáveis, da próxima vez vc conhece a estoria direito antes de falar besteira.

Fico realmente impressionado com o seu conceito de “blogs antigos” , mesmo sabendo que o GF 3.1 só saiu em FINAL FEVEREIRO voce continua a falar besteiras sobre atualizar com versões betas.

Seus argumentos para justificar esta PISADA NA BOLA da JBoss acabaram lá traz quando voce veio com esse papinho mole de “inexperiência em testes” ,

Hoje o WELD não tem mais esse BUG , Faz um pouco mais de UM MES que isso foi corrigido para lançamento da versão estável dentro do GF…

Se voce usa só @Inject em seus projetos é uma pena. Está perdendo uma API fascinante , e melhor de tudo , um padrão.

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ê.

Interessante. Leia a Mundo Java edição 40 (março/2010) e você saberá o que uso em meus projetos.

Alessandro Lazarotti:

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ê.

Pelo visto ou voce é CEGO ou se faz de CEGO… o FIX na ARVORE está lá… uma ARVORE que para quem não usa o JBoss AS é inutil devido a mudança de planos do Peter. NENHUMA versão 1.1.0 funciona no GF 3.0, duvida ? Pergunte ao Peter , então não me venha com xurumelas !

Sentir-me confortavel ? Voce sente-se confortavel em trocar um AS estavel por outro INSTAVEL simplesmente prq o Peter não faz backport de um problema tão importante ? Que tipo de aplicação que vc faz ? Para posto de gasolina ?

Existe uma versão PAGA do Weld ? Aonde eu compro ?

NAO DEPENDE DO GLASSFISH quem reescreveu a interface foi o Peter, justamente prq era um parto atualizar.

Repito , estou JUSTIFICANDO prq chamo de BOMBA o WELD, lembrando que este “detalhe bombastico” foi corrigido…

e o melhor… sem precisar refazer meus testes !!!

hehe

ps: Agora posso chamar a JBoss de comunidade denovo ? DECIDA-SE !

Interessante. Leia a Mundo Java edição 40 (março/2010) e você saberá o que uso em meus projetos.

Bom , a sua declaração aqui diz que é tão facil arrumar este “probleminha” né ?

é só tirar o @Inject…

e “Vou-la” !

OU voce foi “ingenuo” nesta declaração OU realmente NEM VOCE acredita no que escreveu.

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á

Alessandro Lazarotti:

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.

Quem está xoramingando aqui é você , é uma BOMBA e ponto final.(antes mais do que hoje)

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.

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”

Agora de “inocente” virei um “não apto”.

Seus argumentos acabaram (Eu acho que já li isto em algum lugar)

esta frase serve para voce:

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: Agora virou culpa da Oracle que não corrigiu as cagadas do “Maravilhosamente Opensource” Weld.

Argumento do tipo feio, chato, bobalhão… passo

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”

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).

1. Quem chamou de “beberao” foi voce , apenas estou repetindo

2. Repito , voce acha que UM MES de lançada uma versão nova de APP Server toda a galera pode AUTOMAGICAMENTE sair colocando ela… repito PERCEBO como vc nunca lidou com esta situacao…
   E pior… continua culpando os leaks do WELD 1.0 pelo simples fato da “inexperiência” … só se for a inexperiência em utilizar produtos da JBoss , ai sim… pode até ser… Pelo visto até os funcionários dela tem o pé atrás com seus projetos/produtos.

3. 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”.

Agora se vocÊ quer apoiar toda essa baboseira que voce esta dizendo sobre “experiencia em testes” justificando que o problema ocorreu A DEZENAS DE MILHARES DE segundos atras… é um problema seu…

Agora mudar um projeto grande de uma versao de AS para outra e ainda “dar risada” é uma tarefa que nem sempre é facil… afinal , no meu caso não é só tirar os @Inject.

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 :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

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 ;)

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…

Poderia colar aqui estes “vários” tutoriais ?

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

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?

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

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:

Noticia sobre Seam 3.0.0, e 6 paginas de discussão sobre WELD!!! Maravilha em!!!

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.

Lembrando que o WELD é o “motor” do Seam 3.

chun:

Lembrando que o WELD é o “motor” do Seam 3.

Já que o assunto do tópico voltou e os ânimos amenizaram, alguém sabe se é possível usar o Seam sem usar EJB? Se for possível, tem vantagem?

É 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

Aos usuários do Glassfish e Jetty que pretendem utilizar o Seam 3.0 :

http://planet.jboss.org/post/weld_1_1_1_final

olá, alguém aqui tentou construir os exemplos que vêm no seam 3 com o maven?

é pra rodar no jboss as 6

eu tentei e fica dando erro, se alguém quiser me ajudar a como prosseguir, eu agradeço e muito

Opa, aproveitando o topico sobre o Seam 3…

Alguém sabe se o processo de migracao do seam 2.2 pro seam 3 é complexo? Não entendi ainda quais daqueles modulos eu necessitaria.

Tenho um projeto basico com CRUDs gerados pelo seam-gen e queria mudar pro seam 3.

Obrigado.

E aí, alguem sabe como transformar do seam 2.2 pro 3?