0 Replies Latest reply on Jan 3, 2011 10:33 AM by mbalazs

    EJB's and classloading

    mbalazs
    mbalazs Jan 3, 2011 10:33 AM

      Hello!

       

      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