error accessing an EJB via JNDI

[loucs]

i have a strange error accessing an EJB session from a jndi lookup :

Infos :
JBoss 4.2.2.GA
JBossPortal 2.6.4.GA
EJB3

my session bean is in an ear package containing portlets for portal.

i'm trying to do the jndi lookup from a jar called by jboss portal (not from my ear).

I can see in the jmx console that my EJB is bind to the global JNDI namespace and i get the right object from my lookup.

My problem is that i got an exception when i try to cast the object i got from jndi to the local or remote interface of my ejb session, althought i verified that the object i got was really implementing my ejb interface (with getClass().getInterfaces() )

i think it might has something to do with the fact that my EJB interface is deployed in the ear and in a separate jar file in the portal's libdir (but it's the only way for me not to have a class not found exception, as jboss portal classloader can't access my ear classes.

if someone has even the tiniest clue on this matter, i'd take it with pleasure :)

see the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&t=134638

Regards,

--
Lucas
Montes

[jaikiran]

You did not post the actual exception stacktrace, which might give us an idea what the problem is.

[jaikiran]

Ok, i read that other post of your's and looks like a classloading issue.

i think it migth be caused by the fact my local or remote interfaces are in a jar in the libdir of portal, and also in my ear.

Have you enabled classloading scoping for your EAR? You can do so by adding a jboss-app.xml in the META-INF folder of your EAR. The jboss-app.xml should contain:

<jboss-app>
 <loader-repository>
 org.myapp:classloader=MyAppClassloader
 <loader-repository-config>
 java2ParentDelegation=false
 </loader-repository-config>
 </loader-repository>
</jboss-app>

See this for more details http://wiki.jboss.org/wiki/ClassLoadingConfiguration

[loucs]

thanks a lot for the hint.

I'm using reflection for now (getMethod, methode.Invoke) on the object i lookup but i will continue to investigate this cast exception, and so i'll look at your link and try this.

thx again,

--
Lucas
Montes

[loucs]

i finally found where this strange acting comes from. it's actually the contrary of your suggestion. defining a loader repository is the cause of the problem, and when i don't define any, the cast of the object accessed by jndi in the local interface of my EJB is going perfectly well.

the unifiedClassLoader originally defined in my ear is for jboss seam. unfortunatelly, the jar of seam is inside my ear. I didn't create the project, i'm just working on it so i don't know the fundamentals of seam usage and how to deploy correctly a project using it, but for now, the elimination of the <loader-repository> definition in jboss-app.xml is causing the malfunction of jboss seam. i will continue to use the reflection API for now while looking in the seam documentation a manner to deploy it with my project without defining a loader repo in my ear (deploying it ini the jboss libdir for exemple.. or in a separate app, maybe....)

[loucs]

so the problem is caused by the isolation of classloading in my ear.

I tested by putting the attribute calledByValue in default/deploy/conf/jboss-service.xml and it worked, but it's not an acceptable solution as it has repercutions on all jndi lookups, and it increase a lot the ressource usage of such operations.

that's why i'd like to know how to force the calledbyvalue on an EJB3 lookup (and only on one EJB)

i'm searching a lot by myself, (maybe not the right way :), but any clues or link to a corresponding documentation would really help me. (i found some docs but all ejb2 / jboss < 4.2.2.GA related... i don"t has enought knowledge of EJB's to adapt those solution by myself (for now :)

thanks,

--
Lucas
Montes

[loucs]

problem solved :) i've done a lookup forcing the marshalling for method invocation (called-by-value) by putting the full scheme in the lookup :

new InitialContext("jnp://localhost:1099/EJBJndiName");

(my project manager wanted to keep the scoping of classloading for my ear so that was the less ugly way to do it :)