A nova versão do JBoss Seam esta disponível para download com muita coisa boa.
Agora independente de vez do JSF em seu core… integrações com Quartz, JfreeChart… possibilidade de criação de componentes Seam com Groovy entre outras features:
http://in.relation.to/Bloggers/WhatsNewInSeam2
download:
http://labs.jboss.com/jbossseam/download/
docs:
http://docs.jboss.org/seam/2.0.0.GA/reference/en/html/index.html
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…
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?
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) ?
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.
[quote=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?[/quote]
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.
[quote=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) ?[/quote]
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.
[quote=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?[/quote]
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.
[quote=rodrigoy][quote=jonataswingeter]
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]
[/quote]
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
[quote=Leonardo3001][quote=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?[/quote]
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.
[quote=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) ?[/quote]
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.
[quote=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?[/quote]
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.[/quote]
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:
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.