Jboss Seam 2.0.0 GA liberado

Assuntos Gerais Notícias
#21

[quote=rodrigoy]Peraí, vcs não estão confundindo com EJB 2.1? :?:

É esse o raciocínio de vocês: se precisa ser distribuido usa EJB, se não precisa usa Spring?

Estou usando EJB 3 nesse meu projeto e pelo menos nesse momento (como já falei) a aplicação não necessitará escalar. Uso EJB 3 porque tem DI, Gerenciamento de Transação, Anotações, Remoting e facilidade de desenvolvimento. E também porque tenho nojo de XMLs (isso é pessoal) :wink: :wink: :wink:

No meu projeto grande parte da navegação está definida em retornos de métodos das minhas Actions/Façades que são SFSB. Por algumas razões também tem algumas façades que são SFSB que dependem de HtmlTree. Qual a opinião de vocês a respeito:

  1. É pecado e você queimará no marmore do inferno
  2. Você é um arquiteto cowboy, seu código é um lixo… vai programar em VB
  3. Porque não faz em Asp.NET?
  4. Sua aplicação tem uma restrição arquitetural que sua camada de aplicação só serve para páginas Web, e o impacto disso é…

Jonatas, tem um link aqui que pode te ajudar… pelo que entendí, se as conversas estão em cache não precisa mesmo separar o Tomcat do AppServer, mas não estudei a fundo… (é do release anterior)

http://docs.jboss.com/seam/1.2.1.GA/reference/en/html/cache.html
[/quote]

Oi Rodrigo.

Acho que fico com a resposta 4. :slight_smile:

Particulamente faria o que vc está fazendo…sem problemas…mas sem o EJB e pensando em termos de presentation layer.

Quanto ao cache, pela doc que vc passou, a princípio parece que o cache dele pode ser distribuido.
Seria interessante ver uma aplicação deste tipo rodando…

Infelizmente os frameworks, em suma, não possuem POC (Prove of Concept). Não estou dizendo exemplos de como codificar e usar o Seam, mas situações reais para fins específicos. Se isto fosse feito, a maioria dos bugs e problemas seriam previamente solucionados e haveria maior adesão ao produto.

Aí o arquiteto de software faz um POC para um Seam, por exemplo, e nas primeiras situações diversos problemas são encontrados. O que ele faz? desiste do produto. Mas o pior não é isso…
Pior ainda é ele não fazer POC e aderir ao produto porque tem alguma informação no ChangeLog ou doc que diz suporte a alguma coisa. O kra coloca o framework no projeto e depois de alguns meses começa a se deparar com diversos problemas, e na maioria bugs…e ferra o projeto dele.

O JSF é um exemplo disso (RI da Sun e MyFaces)…um framework bom, componentizável, mas cheio de bugs.

Bom, por enquanto é isso.

Att.,

#22

Beleza Jonatas… he he he… :lol:

Minha colocação foi meio dura porque fico meio fulo quando vejo esses programadores “puritanistas” que confundem restrição arquitetural, code smell, débito técnico.

[adicionado] (encontrei com um desses que falou que na empresa dele “era pecado” colocar um HtmlTree na fachada, e por conta disso, criaram uma camada a mais na aplicação só por conta disso. [/adicionado]

Abraços

#23

Olá, boa tarde.

Bem, então Removing the JSF dependency é uma contradição em relação a versão 1.0.
Olhei o código e aquilo nada mais que é tentar englobar o mundo.
Pode ter certeza que o Seam não vai conseguir englobar TODOS os frameworks sem precisar de alguma modificação. É só olhar o JIRA com a lista de bugs. Imagine qualquer framework ser integrável com Seam…aquela lista vai crescer exponencialmente. Não diga que se usar uma arquitetura agnóstica com JSON, XML, etc…vai funcionar, pois os frameworks web tem diferentes técnicas e comportamentos em seu core.
E ao contrário do que você disse, continuo achando que o Seam é uma emenda (do próprio inglês) pro JSF.

Este framework nasceu através de um conjunto de idéias da JSR 299 (Web Beans). Obviamente ele não é a
implementação desta própria JSR, mas a idéia dele era desenvolver uma solução baseada no Web Beans e numa fase posterior, a versão do Web Beans poderia ser totalmente implementada.

A própria JSR 299 está altamente acoplada aos comportamentos do JSF e agora o Seam 2 vem dizer que quer desacoplar dependências JSF… :slight_smile: Além de contraditório, isto só é marketing para ganhar o concorrente.

E a propósito: Viu quem é o leader desta JSR?? :lol:

[quote=Lezinho]
Você não precisa colocar regras de navegação em classes java. No arquivo pages.xml do Seam você pode colocar regras que associam um determinado método da classe Java com seu sucesso de execução ou não. Se o método foi executado com sucesso você é redirecionado para uma página, caso ocorra uma “determinada” exceção você decide no xml qual fluxo seguir. Mas vc tbm pode como JSF, retornar uma String contendo um alias.

Um método de Services retornar uma String não é acoplamento algum, mas se você não deseja isso para sua arquitetura você pode optar por não utilizar EJB no primeiro nível de componentes Seam, e isso tbm responde sua questão sobre fazer bindigs de componentes. O Seam não obriga você usar EJB, um componente Seam é um POJO, que pode ou não ser Remote. Você pode ter um POJO normal atuando para bindings e utilizar uma Façade injetada pelo próprio Seam para isolar sua lógica se você assim preferir.[/quote]

Isto que vc falou é legal…Não necessariamente deve ter regras de navegação. No entanto, existe um acoplamento lógico. :slight_smile:
Se você está retornando “sucesso”, “falha”, obviamente você está pensando em presentation layer. É ou não é???

Se eu tenho um WebService que utiliza SLSB e este retorna qualquer coisa que não seja pertinente, já é uma quebra de conceito.

Quanto a injeção de lógica e deixar a classe utilizando a Façade…achei interessante. Já é algo legal para se pensar.

por enquanto é isso.

Att.,

#24

[quote=rodrigoy]Beleza Jonatas… he he he… :lol:

Minha colocação foi meio dura porque fico meio fulo quando vejo esses programadores “puritanistas” confundem restrição arquitetural, code smell, débito técnico.

Abraços[/quote]

Opa!

Que é isso Rodrigo, fica frio. :slight_smile:

Estas discussões servem para nos enriquecer mesmo! ehehehehehe

Abraço!

#25

[quote=rodrigoy]Peraí, vcs não estão confundindo com EJB 2.1? :?:

É esse o raciocínio de vocês: se precisa ser distribuido usa EJB, se não precisa usa Spring?

Estou usando EJB 3 nesse meu projeto e pelo menos nesse momento (como já falei) a aplicação não necessitará escalar. Uso EJB 3 porque tem DI, Gerenciamento de Transação, Anotações, Remoting e facilidade de desenvolvimento. E também porque tenho nojo de XMLs (isso é pessoal) :wink: :wink: :wink:

No meu projeto grande parte da navegação está definida em retornos de métodos das minhas Actions/Façades que são SFSB. Por algumas razões também tem algumas façades que são SFSB que dependem de HtmlTree. Qual a opinião de vocês a respeito:

  1. É pecado e você queimará no marmore do inferno
  2. Você é um arquiteto cowboy, seu código é um lixo… vai programar em VB
  3. Porque não faz em Asp.NET?
  4. Sua aplicação tem uma restrição arquitetural que sua camada de aplicação só serve para páginas Web, e o impacto disso é…

Jonatas, tem um link aqui que pode te ajudar… pelo que entendí, se as conversas estão em cache não precisa mesmo separar o Tomcat do AppServer, mas não estudei a fundo… (é do release anterior)

http://docs.jboss.com/seam/1.2.1.GA/reference/en/html/cache.html
[/quote]

Eu não sei se tem muito a ver com a sua indagação. Mas desconfio que os Session Beans não são muito eficazes quando se busca escalabilidade (reparem que estou dizendo “desconfio”, não precisa ficar nervosinho se discordar de mim). A razão disso é que as invocações são síncronas (ou seja, quando é chamada a invocação remota, o cliente fica ali parado retendo memória e outros recursos) e seqüênciais (ou seja, se o cliente precisar chamar dois EJB, o segundo não será chamado enquando o primeiro não terminar), quando deveria ser assíncronas e paralelas, como se fosse um esquema de fork/join, que, infelizmente, não existe um jeito fácil de se fazer em Java.

Mas o EJB, a partir da versão 3, deixou de ser ruim, e está valendo a pena utilizá-lo, mesmo pra quem quer somente o recurso de gerenciamento de transação. O Seam seria muito pior se contasse com o EJB 2.1.

#26

Na pratica Jonatas, para o desenvolvedor tanto faz se ele é uma emenda para o JSF ou não, o que vemos é a praticidade, facilidade e elegância do código ao se desenvolver com o Seam. O próprio JSF ja foi uma ótima sacada da Sun, não vejo mal na sua utilização.

Eu não sou pretensioso em afirmar que o Seam NUNCA vai ser totalmente independente do JSF (na verdade ele ja é)… ou que cada vez vai ser mais bugado e etc. Pra mim o que interessa é ele resolver os meus problemas e dos clientes do software final, o que ele faz perfeitamente.

[quote=jonatasw]No entanto, existe um acoplamento lógico.
Se você está retornando “sucesso”, “falha”, obviamente você está pensando em presentation layer[/quote]

Você nao precisa retornar String alguma, como ja disse no post anterior. Você decide o fluxo através de um flow xml, facinho.

WebServices no Seam sao Componentes que utilizam Façades de outros componentes (podendo ser EJB ou não). Nao possui nada de lógica da camada de aplicação.

#27

[quote=Lezinho]Na pratica Jonatas, para o desenvolvedor tanto faz se ele é uma emenda para o JSF ou não, o que vemos é a praticidade, facilidade e elegância do código ao se desenvolver com o Seam. O próprio JSF ja foi uma ótima sacada da Sun, não vejo mal na sua utilização.

Eu não sou pretensioso em afirmar que o Seam NUNCA vai ser totalmente independente do JSF (na verdade ele ja é)… ou que cada vez vai ser mais bugado e etc. Pra mim o que interessa é ele resolver os meus problemas e dos clientes do software final, o que ele faz perfeitamente.

Você nao precisa retornar String alguma, como ja disse no post anterior. Você decide o fluxo através de um flow xml, facinho.[/quote]

Não estou dizendo que o Seam é um lixo…até porque ele resolve alguns problemas do JSF. Mas ao meu ver, ele foi criado pra resolver problemas no JSF. Agora se ele quiser resolver problemas de outros frameworks… vamos ver. :slight_smile:

A sacada da Sun foi em criar um framework Web para ser adotado pelo mundo, já que pouquíssimos utilizavam os recursos puros de JSP e Servlet. A Sun SEMPRE vai tentar forçar seus produtos.

[quote=Lezinho]
WebServices no Seam sao Componentes que utilizam Façades de outros componentes (podendo ser EJB ou não). Nao possui nada de lógica da camada de aplicação.[/quote]

Legal. Então quer dizer que posso ter um SLSB como WebService e isso ser transparente ao Seam, correto?
Ele expõe o serviço como WebService também, certo?

Valeu

Att.,

#28

Fala Davy…
como descrito nas novas funcionalidades do Seam 2, usar ou não o JSF passa a ser opcional…

Removing the JSF dependency
The Seam core has been completely overhauled. In addition to extensive packaging changes, Seam has now been de-coupled from JSF so that it can be more easily used with other web frameworks. We’ve included some experimental GWT integration that shows how this might work. Want Seam with your favorite web framework? We’ve opened the doors for the ambitious.

Segundo o que sei o Seam fará parte da nova especificação do Java EE…

referência:
http://in.relation.to/Bloggers/WhatsNewInSeam2

#29

Paulo,

Como escrevi em outro post, isto é contraditório com a primeira versão do Seam e com o Web Bean JSR 299.

EU não entendo o porquê querer abranger qualquer framework…Se diferentes frameworks tem diferentes comportamentos em seu core.

[quote=paulovittor23]
Segundo o que sei o Seam fará parte da nova especificação do Java EE…

referência:
http://in.relation.to/Bloggers/WhatsNewInSeam2[/quote]

Só se eles reescrevem a JSR 299 Web Bean. Digo isto pois a JSR 299 se focaliza no JSF e o Seam 2.0 quer ficar independente do JSF… :slight_smile:
Se você olhar, o intuito desta JSR é padronizar o JSF como framework, com os recursos do Seam.

Att.,

#30

concordo Jonatas, mas apesar de não fazer mto sentido é algo opcional usar o JSF… não estou defendendo quem não usa rs, msm pq eu uso :wink:

perfeito, ou seja, Seam fará parte da nova especificação do Java EE.

[]s

#35