Servidores de Aplicação (Incompatibilidades)

JBoss Seam foi feito para rodar no JBoss…existe um monte de configurações customizadas para rodar nos outros (o que eu nunca vi).

O glassfish v3 possui o padrão do jee 6.
Então teoricamente qualquer outro servidor que usa essa especificação deve rodar seu aplicativo.
Então verifica se seu aplicativo utiliza o jee 6 e procura servidores com essa especificação.

Eu entendo sua preocupação giulianocosta. Conforme otaviojava já disse, se a aplicação é jee 6 deve rodar sem problemas no GF3. Infelizmente os servidores hoje em dia “puxam um pouco a sardinha” para os frameworks que representam ou vêm das empresas e/ou grupos open-source que os desenvolvem. É o caso do Jboss com o Seam e o Hibernate, o Glassfish com o eclipse link e JSF 2 e assim por diante. Isto reflete apenas em mais ou menos trabalho para configurar a aplicação no servidor. Por exemplo, uma aplicação Seam vai ser muito mais fácil de rodar no JBoss do que no Glassfish ou Weblogic. Já tive problemas com o provider do JPA, estava usando o Weblogic v10 que por padrão usava o Kodo e aí quando tentei colocar o toplink simplesmente não funcionava!
Especifique um pouco melhor seu problema, apesar da sua preocupação ser pertinente, não deve ser nenhum pesadelo portar uma aplicação de um servidor a outro.

Concordo com o amhfilho.

Se você utiliza o framework de uma empresa você acaba se fechando a ela, mas quando você dar prioridade a uma especificação é bem mais provável em funcione com diversas implementações é o caso do jee6.

Blz! Cara, está explicitado aqui o meu problema.

Minha aplicação é Seam 2 based. Pelo que dizem nos fórums é melhor eu aguardar a versão 3 (Weld antiga WebBeans). O que não entendo é como pode dar um erro de incompatibilidade das minhas libraries com as libraries do container. Sendo que se meu pacote possui uma pasta lib, eu estou explicitamente dizendo ao ClassLoader para usar ela e não a do classpath do container ou do SO.

Isso que me indigna. :evil:

E mais, como um WebApplication pode ser certificado tendo essas pendengas de incompatibilidades? hehehehehhe…Não da pra entender.

otaviojava:

Concordo com o amhfilho.

Se você utiliza o framework de uma empresa você acaba se fechando a ela, mas quando você dar prioridade a uma especificação é bem mais provável em funcione com diversas implementações é o caso do jee6.

Cara, como assim? Hehehehehee…

Então quer dizer se eu usar um jar da apache só vou poder usar o Tomcat pra rodar? hehehehhehehehe

Não tem cabimento isso. Uma aplicação java, que obedecer os padrões de empacotamento deve rodar em qualquer servidor certificado para tal.

Deveria pelo menos :shock:

Normalmente o apache utiliza os padrões então vc pode usar em qualquer servidor sem problemas.
Mas tem empresas que fazer com que o recursos rodem apenas em um ambiente, normalmente o deles, e quando vc mudar pode ficar na mão.
Então quanto mais libs e jar você usa dentro dos padrões como por exemplo o hibernate com jpa faz com que vc não fica preso ao hibernate podendo trocar por outro framework.

Pois é, de repente eu tenha começado meu tópico de forma errada.
Na verdade eu queria abrí-lo para deixar publicado minha indignação com esses servidores de aplicação.

Me lembro que antigamente eu podia migrar do tomcat para o WebSphere e depois ir pro OC4J numa boa, mudando coisas básicas como pools de conexões, configuração dos EJBs, etc.

Lamentável.

giulianocosta, a medida que vamos utilizando frameworks e ferramentas que nos auxiliem no desenvolvimento a coisa vai ficando um pouquinho mais complicada. Você começa a ter uma árvore de dependências muito forte, por exemplo o hibernate utiliza o slf4j ao inves do log4j, e dependendo do servidor (já tive problemas com Glassfish 2.1) pode dar alguns conflitos sim! Se você fizer uma aplicação web com servlet puro, somente com as bibliotecas RI da Sun, utilizando apenas os padrões, esta portabilidade acontece mais fácil.
Já tentou criar uma aplicação JEE pelo wizard do Rational App Developer 7.5 rodando num servidor WAS 7? Meu amigo, se fizer isso você tá preso a IBM pelo resto da vida!!
Realmente não deveria funcionar assim, mas a medida que vamos nos beneficiando de frameworks mais proprietários (mesmo que código aberto) estes problemas começam a acontecer. É o preço que pagamos pela produtividade.

amhfilho:

giulianocosta, a medida que vamos utilizando frameworks e ferramentas que nos auxiliem no desenvolvimento a coisa vai ficando um pouquinho mais complicada. Você começa a ter uma árvore de dependências muito forte, por exemplo o hibernate utiliza o slf4j ao inves do log4j, e dependendo do servidor (já tive problemas com Glassfish 2.1) pode dar alguns conflitos sim! Se você fizer uma aplicação web com servlet puro, somente com as bibliotecas RI da Sun, utilizando apenas os padrões, esta portabilidade acontece mais fácil.
Já tentou criar uma aplicação JEE pelo wizard do Rational App Developer 7.5 rodando num servidor WAS 7? Meu amigo, se fizer isso você tá preso a IBM pelo resto da vida!!
Realmente não deveria funcionar assim, mas a medida que vamos nos beneficiando de frameworks mais proprietários (mesmo que código aberto) estes problemas começam a acontecer. É o preço que pagamos pela produtividade.

amhfilho, concordo que há um nível cada vez mais alto de complexidade. Mas o container tem que te prover isolação. O que poderia ocorrer é bibliotecas de um mesmo projeto se colidirem. Isso sim.

Não minhas bibliotecas colidirem com as do container. E nem com as de outras aplicações.

A forma como os servidores de aplicação trabalham diferem muito de uma implementação para outra. Por conta dos recursos que oferecem para nos prover facilidade e produtividade, muitas vezes em situações mais específicas estes problemas podem acontecer. Isto porque a JCP apenas estabelece uma especificação e a implementação fica a cargo de cada fabricante.

Isto realmente não deveria acontecer, principalmente se você está utilizando as bibliotecas carregadas em sua aplicação ( e não no local compartilhado pelo container). O que eu já vivenciei são alguns conflitos com bibliotecas de log (em razão do servidor muitas vezes fazer uso destas libs internamente) e também com implementação de JPA. Também já tive problemas ao tentar utilizar a biblioteca do facelets compartilhada no Glassfish 2.1, pois ele as utiliza em seu console administrativo. Neste caso tive que isolar e duplicar estas libs no WEB-INF/lib da minha aplicação.

Pois é, vou ler mais a respeito disso. Pelo que aprendi nos primórdios era que o ClassLoader sempre abedece a seguinte ordem:

Classpath Aplicação(WEB-INF/lib e WEB-INF/classes), Classpath Container e Classpath do SO. A principio, pra mim, isto parecia ser uma regra de implementação.