Uploaded image for project: 'Application Server 3 4 5 and 6'
  1. Application Server 3 4 5 and 6
  2. JBAS-8126

CNFE Exceptions due to the wrong classloader being used

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 6.0.0.M4
    • JBossAS-5.1.0.GA
    • EJB2
    • None
    • Release Notes
    • Hide

      Here is the workaround we suggested and it seems to have fixed the issue for now public class MyThreadBean extends EJEntityBean { public void test(){ // Assuming the CL is jacked up /*** WORKAROUND ***/ ClassLoader previousClassLoader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader ( this.getClass().getClassLoader() ); try

      { final Object obj = getJndiContext().lookup(jndiName); LoggerLocal myBean = LoggerLocal.class.cast(obj); System.out.println("ThreadBean test"); }

      catch (NamingException e2)

      { e2.printStackTrace(); }

      finally

      { /*** WORKAROUND ***/ Thread.currentThread().setContextClassLoader ( previousClassLoader ); }

      }

      public class ZbpThreadBean extends EJEntityBean {

      public void test(){
      // Assuming the CL is jacked up
      /*** WORKAROUND ***/
      ClassLoader previousClassLoader = Thread.currentThread().getContextClassLoader();
      Thread.currentThread().setContextClassLoader ( this.getClass().getClassLoader() );

      try

      { final Object obj = getJndiContext().lookup(jndiName); BeanLocal myBean =BeanLocal.class.cast(obj); System.out.println("ThreadBean test"); }

      catch (NamingException e2)

      { e2.printStackTrace(); }

      finally

      { /*** WORKAROUND ***/ Thread.currentThread().setContextClassLoader ( previousClassLoader ); }


      }

      Show
      Here is the workaround we suggested and it seems to have fixed the issue for now public class MyThreadBean extends EJEntityBean { public void test(){ // Assuming the CL is jacked up /*** WORKAROUND ***/ ClassLoader previousClassLoader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader ( this.getClass().getClassLoader() ); try { final Object obj = getJndiContext().lookup(jndiName); LoggerLocal myBean = LoggerLocal.class.cast(obj); System.out.println("ThreadBean test"); } catch (NamingException e2) { e2.printStackTrace(); } finally { /*** WORKAROUND ***/ Thread.currentThread().setContextClassLoader ( previousClassLoader ); } } public class ZbpThreadBean extends EJEntityBean { public void test(){ // Assuming the CL is jacked up /*** WORKAROUND ***/ ClassLoader previousClassLoader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader ( this.getClass().getClassLoader() ); try { final Object obj = getJndiContext().lookup(jndiName); BeanLocal myBean =BeanLocal.class.cast(obj); System.out.println("ThreadBean test"); } catch (NamingException e2) { e2.printStackTrace(); } finally { /*** WORKAROUND ***/ Thread.currentThread().setContextClassLoader ( previousClassLoader ); } }

    Description

      The unified classloader is used loading an interface from another jar archive in the /deploy when that interface is called from within a scoped EAR rather than the interface included in the EAR itself.

      Our tests show when an interface is in a jar in the deploy directory and also in the scoped my.ear Once passivate gets called from a class within the EAR, that calls that interface, then it throws a ClassCastException on ClassLocal myEJB = ClassLocal.class.cast(obj);
      However it is actually a ClassNotFound, looking in the debugger. We see that instead of using the context of the ejb which would be the EAR classloader, the unified classloader is used instead and hence the resulting exception

      Attachments

        Issue Links

          is incorporated by

          Bug - A problem that impairs or prevents the functions of the product. JBPAPP-5167 CNFE Exceptions due to the wrong classloader being used

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              olubyans@redhat.com Alexey Loubyansky
              skoussou Stelios Koussouris (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: