Miklos Balazs [http://community.jboss.org/people/mbalazs] created the discussion "EJB's and classloading" To view the discussion, visit: http://community.jboss.org/message/578544#578544 -------------------------------------------------------------- Hello! Sorry for double posting it, I posted this question to the JBoss AS deployment forum yesterday, but I just found this forum and I think that more people read it here who may be able to help me with this. I have successfully managed to get myself in classloading hell. :) And I would be glad if someone could help me out with this because I couldn't find enough information to resolve this problem. I am using JBoss AS 5.1. Here is my scenario: I have two top level EAR's: Service.ear and Application.ear Service.ear contains an MBean and a WAR, and has no classloader isolation defined or any other classloader settings modified. Application.ear has an EJB module and a WAR, and has an isolated classloader repository defined in the ear's jboss-app.xml, with java2ParentDelegation enabled. The problem is the following: The MBean in Service.ear is an event dispatcher, and the Application.ear's WAR registers an event listener object in the MBean during servlet context initialization. When the MBean dispatches the event, it can call the event listener registered by the application without problems, however, the event listener needs to use an SFSB, and at that point it fails because it can't access the EJB's remote interface: 2011-01-03 16:30:41,856 ERROR [...] (http-droolsdemo-portal%2F172.16.3.28-8080-1) Could not lookup GwtConsoleClient session bean: javax.naming.NamingException: Could not dereference object [Root exception is java.lang.RuntimeException: Can not find interface declared by Proxy in our CL + BaseClassLoader@2296c1d{vfszip:/opt/jboss-epp-5.0/jboss-as/server/default/deploy/Service.ear/}] (GwtConsoleClient's classes are in the EJB module of Application.ear) I can see that the problem is that the whole call chain was started from within the Service.ear's context, thus it uses its class loader domain. It is unclear to me that what exactly  "BaseClassLoader@2296c1d{vfszip:/opt/jboss-epp-5.0/jboss-as/server/default/deploy/Service.ear/}" means. Does it refer to a classloader repository? If this is specific to the new classloading model in JBoss 5, where can I find a decent description of how it works? Would it resolve the problem if I could somehow delegate the loading of the remote interface to the default classloader, so that that single class would not be isolated? Is it possible to do that? Regards, Miklos Balazs -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/578544#578544] Start a new discussion in JBoss Microcontainer at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]