Jboss Seam 2.0.0 GA liberado

Lezinho, vc já migrou suas aplicações? Tenho um release importante no fim desse mês, acho que vou continuar no bom e velho 1.2.1.GA.

Abraços!

Estou com um questionamento parecido com o seu Rodrigo. Vou optar por manter o desenvolvimento no 1.2.1 GA e fazer testes paralelo com o 2.0.0 GA.

Se for trocar neste momento e surgir complicações, a data para nosso release poderá ser comprometida. Mas se com os testes eu me der bem, em Dezembro farei a migração.

Conforme eu for realizando os testes vou postando aqui.

Lezinho, a sua aplicação manda mails usando Facelets como o manual diz? No meu ambiente o mail não vai nem com reza braba…

java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!

If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.

A typical config looks like this;

<listener>

<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>

</listener>

O problema não é a configuração indicada. Acho que vou ter que debugar o Seam…

Abraços!

Debuguei o Seam e não conseguí chegar a uma conclusão. Tem algum trecho do código que está otimista, pois uma exception ocorre e não é capturada em lugar nenhum, de forma que nem dá pra saber que erro que é.

O que descobrí é que na minha instalação, se faço um template de email simples sem usar nenhuma outra tag facelets o troço funciona. Basta colocar um simples <h:outputText/> que dá o erro acima.

Como que eu faço poara compilar as aplicações exemplos do jboss seam?
Alem desses exemplos qual outra finalidades dele???

Eu ja baixei o apache criei a variavel ANT_HOME mas o windows não acha ela?Existe outra forma de compilar?

Pra quem tá usando o Seam: vocês têm problemas de memória no Eclipse? Meu Eclipse começa dar out of memory depois de uns 10 deployments (no Ant). Depois crasheia o próprio Eclipse.

Só uma pergunta de ignorante, independencia de JSF?
o Seam não vai ser mais uma implementação da especificação?

Tah bem legal a versão 2.0, uma das diferenças que notei foi que o seam-gen já tah trabalhando com a versão do RichFaces 3.1.1, disponibilizando uns componentes bem interessantes…
está até suprindo minhas deficiências em design rs…
Já a versão 2.0 GA também já corrigiu uns bugs do seam-gen, por exemplo na versão anterior ele tava gerando a anotação dos IDs auto-criados de maneira errada…colocava o @Id @ GeneratedValue só que colocava um @NotNull do hibernate-validator…dai logicamente qdo vc ia persistir a entidade o hibernate-validator dava uma chiada… coisas simples mas que estão ficando mais redondas
Mas no geral tah valendo muito a pena estudar o JBoss Seam, show de bola !

Olá pessoal.

vocês são os caras que gostam do Seam.

Estava vendo o novo release…

Então…

Queria saber uma coisas…

1. O Seam não mata a idéia do EJB de ser uma aplicação distribuída?
   Por exemplo, tenho uma arquitetura N-tier e estou precisando escalar o servidor de aplicação
   pois houve um acréscimo alto do uso dos serviços. Se eu distribuir essa aplicação,
   terei acoplado junto ao EJB o jboss seam, que por sua vez é acoplado ao JSF.
   Eu precisaria então ter o tomcat e o jboss no mesmo server para escalar?

2. Como eu posso pensar em POJO utilizando um serviço EJB sendo que meu EJB
   representa as próprias ações do Presentatior Layer? Isto não me forçaria a pensar
   de um modo procedural (Transaction Script) ?

3. Ex: Meu change request tem a necessidade de trocar o presentation layer
   pois o cliente quer uma interface de usuário mais amigável (RIA), e precisarei
   retirar o JSF. Precisarei refatorar a camada de aplicação inteira para desacoplar
   o Seam (anotações, páginas de retorno, etc). Como seria isto?

Fico no aguardo!

Valeu,

Não chequei a estudar a fundo isso pois a aplicação que estou fazendo nele não é para milhares de usuário, porém, como está baseado na consistente implementação do Jboss EJB 3, não vejo problema de escalar. Também não vejo muito ganho separar o Tomcat do Jboss para escalar. Bom, o Seam se posiciona no mercado como uma alternativa “Enterprise Level” de desenvolvimento rápido concorrendo com o Rails. Espero que eles tenham uma boa alternativa para clusterring.

Jonatas, estou usando o Seam e é o projeto web mais DDD que fiz até o momento. Lembre-se que é EJB3. O fato de você poder colocar um SFSB como camada de aplicação bindada direto na página não gera nada procedural. Estamos usando SFSB como Application Façade [Fowler], e neles, só ficam regras do objetivo do usuário, não necessariamente regras de view (essas ficam no xhtml). As regras de negócio ficam todas no Domain Model logo abaixo. Você viu algum exemplo? O que achou procedural ou TS neles?

Estou usando Facelets e MyFaces e minhas páginas são todas muito ricas e AJAX. O que você chama de RIA? Sei que existem exemplos de integração do Seam com Flex, mas no meu caso, a implementação JSF já me gera páginas ricas.

jonataswingeter:

1) O Seam não mata a idéia do EJB de ser uma aplicação distribuída?
Por exemplo, tenho uma arquitetura N-tier e estou precisando escalar o servidor de aplicação
pois houve um acréscimo alto do uso dos serviços. Se eu distribuir essa aplicação,
terei acoplado junto ao EJB o jboss seam, que por sua vez é acoplado ao JSF.
Eu precisaria então ter o tomcat e o jboss no mesmo server para escalar?

Não mata não. O Seam não força uma arquitetura, apesar de dar preferência a interfaces locais, ainda é possível usar o EJB que está em outra máquina, porém usando a anotação tradicional @EJB.
É preciso entender também que o Seam, assim como muitos framworks por aí, não é distribuído em um único JAR. Na aplicação final, haverá uns Jars na parte web, e outros Jars na parte EJB.
E uma última coisa, é muito difícil chegar a uma situação onde é necessário distribuir a aplicação, e nem sempre traz resultados efetivos.

jonataswingeter:

2) Como eu posso pensar em POJO utilizando um serviço EJB sendo que meu EJB
representa as próprias ações do Presentatior Layer? Isto não me forçaria a pensar
de um modo procedural (Transaction Script) ?

A partir do EJB 3.0, o bean que implementa as interfaces do EJB virou POJO. E só por isso, a sua colocação cai por terra.

jonataswingeter:

3) Ex: Meu change request tem a necessidade de trocar o presentation layer
pois o cliente quer uma interface de usuário mais amigável (RIA), e precisarei
retirar o JSF. Precisarei refatorar a camada de aplicação inteira para desacoplar
o Seam (anotações, páginas de retorno, etc). Como seria isto?

O que eu vi é que o Seam pode ser usado com Groovy ou GWT, ao invés de JSF. Mas eu não chegeui a testar isso. O que eu estranhei é que a “a interface de usuário mais amigável” (e você ainda colocou a sigla RIA, como se ambos fossem a mesma coisa) não significa trocar a tecnologia de apresentação. Dá muito bem pra pra fazer a interface de usuário mais amigável do mundo usando JSF, só não sei se é o mais adequado. Ainda por cima, é bom lembrar que o managed bean do JSF já é desacoplado das páginas de apresentação.

rodrigoy:

jonataswingeter:

1. O Seam não mata a idéia do EJB de ser uma aplicação distribuída?
   Por exemplo, tenho uma arquitetura N-tier e estou precisando escalar o servidor de aplicação
   pois houve um acréscimo alto do uso dos serviços. Se eu distribuir essa aplicação,
   terei acoplado junto ao EJB o jboss seam, que por sua vez é acoplado ao JSF.
   Eu precisaria então ter o tomcat e o jboss no mesmo server para escalar?
   

Não chequei a estudar a fundo isso pois a aplicação que estou fazendo nele não é para milhares de usuário, porém, como está baseado na consistente implementação do Jboss EJB 3, não vejo problema de escalar. Também não vejo muito ganho separar o Tomcat do Jboss para escalar. Bom, o Seam se posiciona no mercado como uma alternativa “Enterprise Level” de desenvolvimento rápido concorrendo com o Rails. Espero que eles tenham uma boa alternativa para clusterring.

[color=blue]
Opa Rodrigo…Então…gostaria de ver uma aplicação usando Seam ser escalável. Na verdade gostaria de ver isso na prática. Sobre a questão de desenvolvimento rápido…não julgo se é bom ou não…mas se me permite uma maleabilidade em termos de arquitetura.
O que me justificaria usar EJB, seria ter uma aplicação escalável e distribuída. Se vou ter o Presentation Layer e o Application Layer na mesma JVM, não vejo necessidade de ter EJB. Porque não Spring então??
O que eu queria saber mesmo, que não achei até agora…é se o Seam força o Tomcat estar na mesma JVM de um JBoss, por exemplo. É uma dúvida que tenho.
[/color]

Jonatas, estou usando o Seam e é o projeto web mais DDD que fiz até o momento. Lembre-se que é EJB3. O fato de você poder colocar um SFSB como camada de aplicação bindada direto na página não gera nada procedural. Estamos usando SFSB como Application Façade [Fowler], e neles, só ficam regras do objetivo do usuário, não necessariamente regras de view (essas ficam no xhtml). As regras de negócio ficam todas no Domain Model logo abaixo. Você viu algum exemplo? O que achou procedural ou TS neles?

[color=blue]
Na verdade, você tem razão. A minha questão é saber se o pessoal anda fazendo os EJBs como se fossem Actions da presentation Layer e se eu quiser mapear um EJB (Stateless SB, por exemplo) para um WebService,
terei algum problema. Não acho legal associar o EJB como uma ação do presentation Layer retornando a página de web (return "index.xhtml; "). Já vi uns exemplos assim e não achei legal.
[/color]

Estou usando Facelets e MyFaces e minhas páginas são todas muito ricas e AJAX. O que você chama de RIA? Sei que existem exemplos de integração do Seam com Flex, mas no meu caso, a implementação JSF já me gera páginas ricas.

[color=blue]
Talvez não tenha colocado o termo da melhor forma. Vamos dizer que trabalho com desenvolvimento de framework e não acho que pelo fato do JSF poder ter um renderer diferente o mundo brilha e fica tudo bonito, atém porque os comportamentos podem ser diferentes se eu quiser desenvolver componentes com ExtJS, Flex, coocsdo, GWT, etc…Vi um tempo atrás um artigo do Gaving falando sobre a possível integração com outros frameworks, além de JSF. Mas até agora a única coisa que percebi que o Seam é realmente uma Emenda para resolver os problemas do JSF, como manter estado de conversação, IoC de ManagedBeans, abstração do HTTP, etc…Isso é minha visão, se eu estiver errado, por favor me corriga.

RIA é um conceito um tanto subjetivo e quando digo interface amigável, realmente me refiro a um modelo rico mesmo, estilo ExtJS ou Flex. Acho o JSF um pouco engessado, apesar de ser compatível com A4J, DWR…mas na prática existem diversos bugs que vão aparecendo…mas ainda sim é melhor que a maioria dos concorrentes.

Valeu, por enquanto é isso.

Jônatas
[/color]

Olá Leonardo, boa tarde.

A mensagem que respondi ao Rodrigo também serve a você.

Sobre a possibilidade do EJB3 ter POJO, isso não tira a possibilidade do programador de injetar regras de navegação do JSF no POJO, fazendo um acoplamento. Se eu quiser trabalhar com Binding dos componentes no JSF…vou colocar no EJB ou vou usar uma técnica diferente?

Percebe…pra cometer um erro é muito fácil. Já vi alguns exemplos na internet meio feio. Mas se vc tiver uma boa técnica coloca aí pra gente ver…pelo menos o conceito, não precisa do código, eheheheheheh

Att.,

Jônatas

Leonardo3001:

jonataswingeter:

1) O Seam não mata a idéia do EJB de ser uma aplicação distribuída?
Por exemplo, tenho uma arquitetura N-tier e estou precisando escalar o servidor de aplicação
pois houve um acréscimo alto do uso dos serviços. Se eu distribuir essa aplicação,
terei acoplado junto ao EJB o jboss seam, que por sua vez é acoplado ao JSF.
Eu precisaria então ter o tomcat e o jboss no mesmo server para escalar?

Não mata não. O Seam não força uma arquitetura, apesar de dar preferência a interfaces locais, ainda é possível usar o EJB que está em outra máquina, porém usando a anotação tradicional @EJB.
É preciso entender também que o Seam, assim como muitos framworks por aí, não é distribuído em um único JAR. Na aplicação final, haverá uns Jars na parte web, e outros Jars na parte EJB.
E uma última coisa, é muito difícil chegar a uma situação onde é necessário distribuir a aplicação, e nem sempre traz resultados efetivos.

jonataswingeter:

2) Como eu posso pensar em POJO utilizando um serviço EJB sendo que meu EJB
representa as próprias ações do Presentatior Layer? Isto não me forçaria a pensar
de um modo procedural (Transaction Script) ?

A partir do EJB 3.0, o bean que implementa as interfaces do EJB virou POJO. E só por isso, a sua colocação cai por terra.

jonataswingeter:

3) Ex: Meu change request tem a necessidade de trocar o presentation layer
pois o cliente quer uma interface de usuário mais amigável (RIA), e precisarei
retirar o JSF. Precisarei refatorar a camada de aplicação inteira para desacoplar
o Seam (anotações, páginas de retorno, etc). Como seria isto?

O que eu vi é que o Seam pode ser usado com Groovy ou GWT, ao invés de JSF. Mas eu não chegeui a testar isso. O que eu estranhei é que a “a interface de usuário mais amigável” (e você ainda colocou a sigla RIA, como se ambos fossem a mesma coisa) não significa trocar a tecnologia de apresentação. Dá muito bem pra pra fazer a interface de usuário mais amigável do mundo usando JSF, só não sei se é o mais adequado. Ainda por cima, é bom lembrar que o managed bean do JSF já é desacoplado das páginas de apresentação.

O retorno de um managed bean tradicional, de um session bean no Seam, ou de um action no Struts 2, não é a página pra onde se vai, mas uma mensagem indicando seu status, como por exemplo: success, loginOk, failed ou qualquer outra string. Haverá um xml de configuração que mapeia esses retornos para a próxima página. Por conta disso, não existe acoplamento na camada de apresentação.

Claro que o Seam passou a permitir algo que o JSF não tinha, que é colocar a próxima página a ser mostrada direto no Session Bean, mas não acho isso recomendável. Apesar disso, dá pra fazer no método que eu descrevi acima.

A palavra “escalável” é mais uma daquelas palavrinhas mágicas que os çábios da Sun usam pra enfiar goela abaixo o EJB. Não existe bala de prata. Achar que é só colocar um EJB numa outra máquina e “seus problemas acabaram” é idiotice.

Fala Leonardo.

Penso como você. A sempre sempre tem alguma justificativa para usar o EJB.

Por isso quando vejo um projeto com EJB, já penso: Qual a necessidade disso?

Att.,

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)

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

Em servidores SMTP com autenticação segura (SSL ou TLS) as versões do Seam 1.2.1 e anteriores funcionam. Porém, para ambientes onde o protocolo não é seguro, existe um bug (se você especifica ssl = false ele tenta se conectar por TLS). Por esse problema eu já passei…
Felizmente tem um simples fix para isso na versão 2.0.0:
http://jira.jboss.com/jira/browse/JBSEAM-1795;jsessionid=F87B53058681F54E96E6F96F775F9CEC?page=all

Quanto ao problema que você relatou de ter componente JSF nas tags facelets gerando algum erro, aqui não tenho esse problema, funciona normalmente (minhas configurações do Seam são baseadas no Red Hat Developer Studio, não no seam-gen).

Aliás, saiu o RC1 do RHDS com suporte ao Seam 2

Na verdade ele nunca foi uma implementação da especificação. Sempre foi necessário você ter os jars da implementação jsf (r.i. ou myfaces) para trabalhar com o Seam. As características e funcionalidades do Seam não são as mesmas do JSF.

O Seam 2 é independente do webframework em seu core. A equipe do Seam faz a prova do conceito com sua integração totalmente independente do JSF com o GWT, em seu tutorial.

http://in.relation.to/Bloggers/WhatsNewInSeam2 (Removing the JSF dependency)

Escopo de conversação, manter estado entre popups e abas de web browsers, gerenciar comportamento quando o usuário utiliza o “back” do navegador e tantos outros recursos não são meramente “emendas” para o JSF, mas sim soluções para qualquer framework web.

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.

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)

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

Oi Rodrigo.

Acho que fico com a resposta 4.

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

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

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… Além de contraditório, isto só é marketing para ganhar o concorrente.

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

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.

Isto que vc falou é legal…Não necessariamente deve ter regras de navegação. No entanto, existe um acoplamento lógico.
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.,

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

Opa!

Que é isso Rodrigo, fica frio.

Estas discussões servem para nos enriquecer mesmo! ehehehehehe

Abraço!

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)

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

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.

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.

jonatasw:

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

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.

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.

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.

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.

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.

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

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

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.

paulovittor23:

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

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

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…
Se você olhar, o intuito desta JSR é padronizar o JSF como framework, com os recursos do Seam.

Att.,

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

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

[]s