Erro ao acessar EJB fora do JBoss

4 respostas
danieldestro

Oi pessoal,

Fiz um EJB utilizando o plugin JBoss IDE. Testei o EJB o chamando diretamente de um Servlet, que está no mesmo JBoss. O código de chamada é o seguinte:

Context ctx = new InitialContext(); Object ref = ctx.lookup("ejb/GPASolicitacaoProcesso"); GPASolicitacaoProcessoHome home = (GPASolicitacaoProcessoHome) PortableRemoteObject.narrow( ref, GPASolicitacaoProcessoHome.class ); GPASolicitacaoProcesso gpa = home.create(); gpa.processar( idProcesso, usuario, params );

Isto funciona muito bem!

Agora, quando eu tento acessar o mesmo EJB, de um programa standalone, eu não consigo. O código do meu programa está assim:

Hashtable props = new Hashtable(); props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); props.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces"); props.put(Context.PROVIDER_URL, "jnp://localhost:1099"); Context ctx = new InitialContext( props ); Object ref = ctx.lookup("ejb/GPASolicitacaoProcesso"); GPASolicitacaoProcessoHome home = (GPASolicitacaoProcessoHome) PortableRemoteObject.narrow( ref, GPASolicitacaoProcessoHome.class ); GPASolicitacaoProcesso gpa = home.create(); gpa.processar( idProcesso, usuario, params );

Porém, eu recebo a seguinte Exception:

javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.proxy.ClientContainer (no security manager: RMI class loader disabled)] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:579) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:440) at javax.naming.InitialContext.lookup(Unknown Source) at dinap.gpa.ejb.TesteA.getHome(TesteA.java:51) at dinap.gpa.ejb.TesteA.main(TesteA.java:65) Caused by: java.lang.ClassNotFoundException: org.jboss.proxy.ClientContainer (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(Unknown Source) at sun.rmi.server.LoaderHandler.loadClass(Unknown Source) at java.rmi.server.RMIClassLoader$2.loadClass(Unknown Source) at java.rmi.server.RMIClassLoader.loadClass(Unknown Source) at sun.rmi.server.MarshalInputStream.resolveClass(Unknown Source) at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source) at java.io.ObjectInputStream.readClassDesc(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at java.rmi.MarshalledObject.get(Unknown Source) at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:30) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:460) ... 4 more Exception in thread "main"

Alguém tem idéia do que pode ser?

Creio que seja algo do lado do JBoss, pois se eu mudo o nome do JNDI para “java:/comp/env/ejb/GPASolicitacaoProcesso”, o Exception é que ele não achou o nome.

4 Respostas

T

Estranho, vi num programa meu que chamava um EJB no JBoss, e ele também punha mais algumas coisas no context:

“jnp.socketFactory” -> “org.jnp.interfaces.TimedSocketFactory”
“jnp.timeout” -> "0"
“jnp.sotimeout” -> “0”

Será que isso faz diferença?

De qualquer maneira, eu sempre ponho as seguintes bibliotecas no classpath:
JBoss 3.0 -> jboss-j2ee.jar, jbossx-client.jar, jboss-client.jar,
jboss-iiop-client.jar, jboss-common-client.jar, jnp-client.jar
JBoss 3.2 -> jbossall-client.jar
Talvez esteja usando bibliotecas demais no caso do JBoss 3.0, mas não custa nada tentar.

danieldestro

Puuutzzzz, pode isso das bibliotecas mesmo. Na verdade eu tava seguindo o exemplo de um JMS, que talvez use menos LIBs. Vou tentar e falo o resultado.

danieldestro

Graaaannnddeeeee thingol. Funfou!
Era falta de JARs.

O foda disso tudo é ter que mandar esse bando de JARs com a aplicação que vai chamar o EJB. Afffffff… 8)

T
  1. Você pode então fazer um “superjar” com o conteúdo dos JARs que são necessários para fazer o seu aplicativo funcionar, ou então deixa como está. (Sabe como é, uma das leis da informática: “funcionou, não mexa”)
  2. Você tem paciência para ver quais são os JARs que são realmente necessários? Eu uso todos eles porque na verdade era só para um ambiente de desenvolvimento, e para não ter de me preocupar se estava faltando alguma coisa. (O aplicativo mesmo era para funcionar no maravilhoso ambiente Sun iPlanet, mas a velocidade de deploy do iPlanet é simplesmente impressionante :x . É por isso que a gente testava aqui em JBoss e fazia um deploy final no iPlanet.)
Criado 18 de novembro de 2004
Ultima resposta 18 de nov. de 2004
Respostas 4
Participantes 2