2 Replies Latest reply on Jan 15, 2011 2:44 AM by ilya40umov

    Why does Thread.getContextClassLoader in an stateless bean r

    yanfengzhang816

      I'm using JBoss AS 4.2.2.

      I worked out an ear with a war and a ejb-jar and several library jars in it. Some more information:
      1. there is a very simple servlet in the war which do nothing more than retrieving some messages from the back-end stateless session beans and showing them in the browser.
      2. In the ejb-jar, I have several stateless beans and an interceptor class which has a method for @PostConstruct. In all the beans and the interceptor, I added something like the following:

      System.out.println("Thread class loader: "+Thread.currentThread().getContextClassLoader());
      System.out.println("local class loader: " + this.getClass().getClassLoader());
      


      The output is somehow amazing to me: the thread class loader is always WebappClassLoader for the stateless beans and interceptor! and the "local class loader" is UnifiedClassLoader3 in stateless session beans and interceptors and in servlet "WebappClassLoader".

      Should not the Thread.currentThread().getContextClassLoader() in stateless beans and interceptors return the same class loader as this.getClass().getClassLoader() (that is UnifiedClassLoader3 instead of WebappClassLoader)? Is that a bug?

        • 1. Why does Thread.getContextClassLoader in an stateless bean r
          lujop

          I've exactly the same problem. Someone has some information about it or some workarround?

           

          What I do is call a local stateless EJB from a Webapp and while executing the EJB code the current class loader seems ok but the thread one is always the webapp.

          • 2. Re: Why does Thread.getContextClassLoader in an stateless bean r
            ilya40umov

            I guess that this is a normal behavior for J2EE 5 container Jboss. Because every war file(inside or outside ear) has its own classloader. For instance I have there war files in my ear and they all have there own copies of my singletons. Another thing is that EJB application has its own classloader and when you call these methods the first string returns your war classloader and the second returns EJB app classloader.

            I guess that if you try to call the same ejb from a standalone client you will find that Thread's classloader is a classloader of this client(I'm not quite sure about this one).

            If you want to read some additional info take a look at the following link:

            http://community.jboss.org/wiki/classloadingconfiguration