Liberada a versão 1.2 GA do JBoss Seam, que trás algumas novidades como:
- Out of the box integration with the Spring Framework;
- EL support in HQL/EJB-QL;
- Entity level security;
- SSL redirection;
Entre outras.
Fonte:TSS
Download: Aqui.
:lol:
Suporte completo ao Spring 
Eu sabia que eles iam dar o braço a torcer, agora é Seam na cabeça 
Suporte completo ao Spring
Eu sabia que eles iam dar o braço a torcer, agora é Seam na cabeça :D[/quote]
Eu sei que vou me arrepender disso… mas vou perguntar…
Com Java EE 5… pra que spring ?
considerando 80% das apps hoje construidas… eu sei que SEMPRE a uma hora que vc precise de uma coisa ou outra… mas o que spring oferece que implicaria em TER SUPORTE NO JBOSS SEAM SENAO NAO USO ?
Não entendi o seu comentário.
O que torna o Spring indispensavel ? até hoje sempre enxerguei o spring como um grande elefante branco na maioria das vezes…
[quote=chun]O que torna o Spring indispensavel ? até hoje sempre enxerguei o spring como um grande elefante branco na maioria das vezes…
[/quote]
Nada, por isso que o pessoal da JBoss resolveu oferecer suporte a ele no Seam.
[quote=Maurício Linhares][quote=chun]O que torna o Spring indispensavel ? até hoje sempre enxerguei o spring como um grande elefante branco na maioria das vezes…
[/quote]
Nada, por isso que o pessoal da JBoss resolveu oferecer suporte a ele no Seam.[/quote]
é que voce falou de uma forma como se “agora que suporta spring eu vo usar”
ae eu pensei “mas o que spring tem tanto que é pré requisito para poder usar o Seam ?”
É é exatamente esse o caso, já não estava usando o Seam porque em alguns casos era um pouco complicado integrar ele com o Spring.
[quote=chun]ae eu pensei “mas o que spring tem tanto que é pré requisito para poder usar o Seam ?”
[/quote]
Pra mim tem muita coisa, mas como você mesmo disse, pra você é só um elefante branco.
Acho que se ele fosse um elefante, estaria mais pra verde do que pra branco
É é exatamente esse o caso, já não estava usando o Seam porque em alguns casos era um pouco complicado integrar ele com o Spring.
[quote=chun]ae eu pensei “mas o que spring tem tanto que é pré requisito para poder usar o Seam ?”
[/quote]
Pra mim tem muita coisa, mas como você mesmo disse, pra você é só um elefante branco.
Acho que se ele fosse um elefante, estaria mais pra verde do que pra branco :D[/quote]
Poderia me citar umas 5 coisas ?
[quote=Maurício Linhares]E lá vou eu engolindo o flame-bait…
http://www.springframework.org/about[/quote]
Desulpe… nao foi a intencao minha comecar uma discussão estilo flame-war… eu REALMENTE gostaria de entender de uma pessoa que já usa… os motivos do uso…
Mas se voce acha q isso vai comecar um flame-war… paremos por aqui.
Bem, não usei o Seam ainda, mas não consegui imaginar um bom motivo para justificar a integração com o Spring. Eu via o Spring como uma opção ao Seam, mas não como um aliado.
Seria realmente interessante saber qual os ganhos com esta integração. 
Como eu já havia dito em um tópico anterior sobre o assunto (acho que foi até outra notícia de release do Seam), os dois nunca foram competidores, o que o Seam faz é apenas facilitar o desenvolvimento de aplicações que usem JSF e EJB 3 ou Hibernate. E o Spring não tem nenhuma parte específica de integração ou facilitação do uso de EJB 3 dentro de páginas JSF, o que ele tem é apenas um variable resolver que disponibiliza os beans do Spring dentro dos beans do JSF.
Não faz (nem nunca fez) o menor sentido vê-los como concorrentes, tanto que agora o Seam adicionou uma integração com o Spring (veja que não é o Spring que vai se integrar ao Seam, é o contrário).
Sobre os porquês de se usar ou não Spring, lá na página do about estão quase todos, os outros são pontuais e específicos demais pra esmiuçar aqui.
Vendo por este ponto de vista faz sentido.
Então talvez um bom exemplo de uso desta integração seria o uso do controle de transação do spring ou até mesmo os JdbcTemplate dentro do Seam? Esses seriam um exemplo de benefícios desta integração?
Obrigado!
Vendo por este ponto de vista faz sentido.
Então talvez um bom exemplo de uso desta integração seria o uso do controle de transação do spring ou até mesmo os JdbcTemplate dentro do Seam? Esses seriam um exemplo de benefícios desta integração?
Obrigado![/quote]
A coisa não é bem assim. Um dos prórprios desenvolvedores do Seam não via muito valor nesse desenvolvimento. O que aconteceu foi um pouco de pressão da comunidade pelas milhares de coisas já desenvolvidas com o Spring.
Particularmente acho uma boa, você poder contar com as características do Spring, como AOP, controle de transações via tal técnica, injeção de dependência de Beans, pois a especificação cobre somente EJB3 com IoC entre outras características do Spring.
Agora, achei rápida essa integração, menos de 2 meses de desenvolvimento.
Uma coisa bem interessante é que a JBoss não quer excluir a comunidade Spring que é forte e vibrante. A BEA deu um passo importante com seu projeto pitchfork, para colocar o Spring em containers JEE , onde vc pode se beneficiar do poder do spring sem ter um container Web para configuração.
Olá
Tenho lido bastante sobre EJB 3 e também sobre Hibernate 3.
Do Spring sou fã há muito tempo e agora com o Spring 2 as configurações ficaram ainda mais fáceis.
Para mim a integração de qualquer coisa com Spring e Hibernate é mais útil do que com as traquitanas da Sun.
Ainda não estou convencido se teria vantagens em usar EJBs 3 onde eu poderia usar apenas Spring 2 (inclusive transações) + Hibernate 3.
Portanto, se o Seam se integra com o Spring, já tem mais chances de atrair minha atenção (até agora não sei nada sobre ele)
[]s
Luca
Só botando um pouco o bedelho na discusssão…
Em já esta se usando java EE e se colocar mais um framework por causa de algumas atividades a mais, vejo que no fim vc cria uma dependência muito grande de vários framework somente por causa de uma ou outra atividade adicional.
Se vc vai fzr persistência e colocar Spring, tem q extender a infra dele pra ele fazer o que vc espera e por aí vai.
Tive que decidir aqui no banco entre, deixar Spring controlando tudo ou segui a especificação Java EE e continuar sem muita dependência de N framework´s tudo junto.
Hoje fazemos AoP com Aspectje consigo utilizar o restante já dado pelo container e Session Bean.
[s]
baiano
[quote=georgesq]Só botando um pouco o bedelho na discusssão…
Em já esta se usando java EE e se colocar mais um framework por causa de algumas atividades a mais, vejo que no fim vc cria uma dependência muito grande de vários framework somente por causa de uma ou outra atividade adicional.
Se vc vai fzr persistência e colocar Spring, tem q extender a infra dele pra ele fazer o que vc espera e por aí vai.
Tive que decidir aqui no banco entre, deixar Spring controlando tudo ou segui a especificação Java EE e continuar sem muita dependência de N framework´s tudo junto.
Hoje fazemos AoP com Aspectje consigo utilizar o restante já dado pelo container e Session Bean.
[s]
baiano[/quote]
Desculpa , nao entendi…
vc lagou o spring ? tah usando que versao do Java EE ? 1.4 ? 5 ?
Bom, se vc engessar sua arquitetura com vários framework é uma boa, isso ai depende do ponto de vista e da disponibilidade de mão de obra interna pra dá manutenção.
Adicionar Spring só por causa de controle de transação, IoC ou AOP e para isso fazer sua arquitetura depender de Java EE e Spring, tenho como é uma péssima.
[s]
baiano
Não larguei, estavamos começando uma nova arquitetura pra o Banco que trabalho e podiamos fazer 2 provas de conceito, Java EE ou Spring, e o custo de dependência com Spring era muito maior que Java EE.
Hoje temos Java EE 1.4, JPA e AspectJ pra fazer o que quizermos faltante.
[s]
baiano