Re: Desespero total

["Ivan Bittencourt de Araujo e Silva Neto" <ivanneto@xxxxxxxxxxxxxxxx>]

Ola Danilo.

On Sat, Dec 11, 2004 at 08:44:29PM -0200, Danilo Conde wrote:
>    Após o dia inteiro de tentativas frustradas de entender o que está 
> acontecendo, acabo de concluir que eu não sei o que está acontecendo.
Eu tambem fiquei um bom tempo nessa situacao. :-)

> 1) Um servidor de aplicações (SA1) com um EJB sessão de fachada para 
> outros entity beans (por acaso, são os EJBs do EP1 - alunos e 
> disciplinas). A sessão com o invoker-proxy-binding para IIOP.
> 2) Um outro servidor de aplicações (SA2) com um EJB sessão que é apenas 
> um proxy para o EJB sessão que está em SA1. Também configurado com o 
> invoker-proxy-binding de IIOP. Ou seja, tudo que o EJB em SA2 faz é 
> delegar os métodos para o session bean que está no SA1.
> 3) Os dois session beans estão configurados, no ejb-jar.xml, para 
> <transaction-type>Container</transaction-type>. Dessa forma, meus EJBs 
> não usam transações em lugar algum.
> 4) Usando o Jboss do jeito que ele é, sem nenhuma alteração minha
> 5) Meu aplicativo cliente de testes chama métodos do EJB que está em SA2
Fiz algo parecido com isso. Coloquei um entity bean em cada SA, sem nenhum
session bean para interceptar as requisicoes. Pelo que me lembro nao coloquei
o transaction-type, mas acho que isso nao faz diferenca.

>    Eu estava usando o serviço de nomes do CORBA (*) no SA2 para pegar a 
> referência do EJB no SA1. Aparentemente, tudo funcionava, mas desse 
> jeito aí, o único interceptador que eu via ser chamado era o 
> TxServerInterceptor. Os outros dois eu não vi serem chamados nenhuma 
> vez...
Acho que nesse caso o TxClientServerInterceptor deveria ser chamado quando
o SA2 delega a chamada para o SA1. E pelo erro que voce informou abaixo ele
realmente deveria estar chamando o metodo send_request desse interceptador.
Pelo que me lembro, o send_request e chamado e manda junto com a requisicao
um PropagationContext vazio.

> 20:10:14,337 ERROR [LogInterceptor] RuntimeException in method: public 
> abstract matricula.GerenciadorDeMatriculas 
> matricula.GerenciadorDeMatriculasHome.create() throws 
> java.rmi.RemoteException,javax.ejb.CreateException:
> java.lang.RuntimeException: Not a TransactionImpl, but a 
> org.jboss.proxy.ejb.ForeignTransaction...
Esse erro acontece porque o TxServerInterceptor.getCurrentTransaction() tenta
importar o contexto transacional, mas nao consegue (porque esta vazio), entao ele
importa essa fake transaction "ForeignTransaction". Se eu nao me engano, o
getCurrentTransaction() chama algo que no fim acaba caindo no
TxManager.importTransactionContext() (algo desse tipo), e acho que é esse cara
que retorna ForeignTransaction.instance. O que eu fiz foi nesse metodo importar
o contexto CORBA e devolver uma transacao valida.

>    A minha principal dúvida é: o ambiente de testes que eu fiz é válido ?
Eu acho que sim, mas e melhor voce ver tambem a opiniao dos experts da lista.

> (**)
> props.setProperty("java.naming.factory.initial", 
> "org.jnp.interfaces.NamingContextFactory");
> props.setProperty("java.naming.provider.url", "jnp://localhost:1099");
> props.setProperty("java.naming.factory.url.pkgs", "org.jnp.interfaces");
Eu fiz exatamente isso dentro do meu EJB. ACho que nao e o jeito mais bonito,
mas aparentemente funciona.

Abracos.

-- 
 Ivan Bittencourt de Araujo e S Neto   <ivanneto@linux.ime.usp.br>