Try setting callByValue property of RemoteNamingBean to true in JBOSS_HOME/server/<servername>/deploy/naming-jboss-beans.xml:
<bean name="RemoteNamingBean" class="org.jnp.server.Main"> ... <!-- The call by value mode. true if all lookups are unmarshalled using the caller's TCL, false if in VM lookups return the value by reference. --> <property name="callByValue">true</property> ...
I have set
<property name="callByValue">true</property>, but I'm still getting the same exception as described above.
I encountered a similar problem today, where injection of resources (jms) into an EJB gave the same "Classloaders of value: BaseClassLoader...", etc. I tried doing jndi lookups for the resources, and got nonsensical ClassCastExceptions, because the resource implemented the interface.
It turned out to be that I was including the jms.jar in my war file, and JBoss's class loader will, by default, prefer local or child versions (where the parent is the container's class loader) of a class over remote ones. That causes the situation where com.acme.Foo != com.acme.Foo (because they're from different class loaders) and unexpected ClassCastExceptions occur. There is lots of information on JBoss class loading here, http://community.jboss.org/wiki/JBossClassLoaderIntroduction.
Anyway, in my situation, simply making the jms jar <scope>provided</scope> fixed the issue. I'm guessing something similar is happening here.
Hope that helps,
In my projects, I have defined javax.ejb::ejb-api with scope provided.
Maybe I have a conceptional missunderstanding of JEE components. To get my JEE universe back to balance, I have attached the maven project, the EARs and a soap-ui test. As described above, the sample covers a simple EJB injection scenario. The exception is thrown not during deployment, but when the WS gets invoked.
Could anyone be so kind and try to deploy the EARs - or have a look at my maven projects.
I took a quick look at your uploaded packages, and you're including the ticket-service-1.0.0.jar file in both ticket-ear-1.0.0.ear and business-ear-1.0.0.ear. So, when your BusinessServiceBean is created by the EJB container (when your web service is invoked), it tries to inject a TicketServiceBean from your ticket-ear-1.0.0.ear package into the bean's member 'ticketService' variable, which uses the TicketService interface. The problem is that TicketServiceBean being injected comes from a different classloader than the TicketService interface that it's being inject into (because of JBoss's classloading strategy). If you remove the @EJB annotation and instead use jndi to look up the EJB, you'll se a class cast exception, for the same reason.
If you make sure that ticket-service.jar is not included in the business-ear, it should work.
I have tested the following scenarios:
1.) business-ear without ticket-service.jar (contains remote interface of referenced EJB).
In this case I get a java.lang.NoClassDefFoundError: Lorg/samples/ticket/TicketService when the EAR gets deployed
2.) Then I have also adopted the Class-Path entry in business-core.jar/META-INF/MANIFEST.MF (business-core.jar contains the EJB implementation that references the TicketService EJB).
changed from Class-Path: ticket-service-1.0.0.jar business-service-1.0.0.jar to Class-Path: business-service-1.0.0.jar
Same result as in 1.
I think, I have to do more reading on JBossAS classloader strategy. Currently my experience is based on IBM WAS. But I thought, that this kind of packaging is conform to JEE standards.
What if you place the ticket-service.jar in the lib folder of your server ($JBOSS_HOME/server/xxxx/lib/)? That should take care of the NoClassDefFoundError you get when deploying business-ear.