You did not post the actual exception stacktrace, which might give us an idea what the problem is.
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
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.
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....)
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 :)
problem solved :) i've done a lookup forcing the marshalling for method invocation (called-by-value) by putting the full scheme in the lookup :
(my project manager wanted to keep the scoping of classloading for my ear so that was the less ugly way to do it :)