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.
[quote=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.[/quote]
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.[/quote]
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.
[quote=chun]Esse Weld tá fod…
Cada vez mais me preoculpo que o “motor” do CDI padrão é uma bomba.
[/quote]
Se preocupe menos e contribua mais:
https://issues.jboss.org/browse/WELD
[quote=Alessandro Lazarotti][quote=chun]Esse Weld tá fod…
Cada vez mais me preoculpo que o “motor” do CDI padrão é uma bomba.
[/quote]
Se preocupe menos e contribua mais:
https://issues.jboss.org/browse/WELD[/quote]
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(?)”
[quote=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(?)”
[/quote]
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
[quote=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[/quote]
-
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…
-
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.
-
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:
[quote=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:
[/quote]
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
[quote=rimolive][quote=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:
[/quote]
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.
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.
[quote=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?[/quote]
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.
[quote=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[/quote]
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)
[quote=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:
[/quote]
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: