3 Replies Latest reply on Dec 12, 2007 11:29 AM by Clebert Suconic

    RepositoryClassLoader::repository Null

    Clebert Suconic Master

      I've been dealing with a JMS TCK Test, and it seems there is a situation where the repository could be null on RepositoryClassLoader.

      java.lang.RuntimeException
       at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:623)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
       at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:467)
       at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:408)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
       at org.jboss.util.loading.DelegatingClassLoader.loadClass(DelegatingClassLoader.java:92)
       at org.jboss.mx.loading.LoaderRepositoryClassLoader.loadClass(LoaderRepositoryClassLoader.java:90)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
       at org.jboss.util.loading.DelegatingClassLoader.loadClass(DelegatingClassLoader.java:92)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
       at org.jboss.messaging.util.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:65)
       at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
       at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
       at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
       at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
       at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
       at org.jboss.messaging.util.StreamUtils.readObject(StreamUtils.java:154)
       at org.jboss.messaging.util.StreamUtils.readList(StreamUtils.java:275)
       at org.jboss.messaging.util.StreamUtils.readObject(StreamUtils.java:147)
       at org.jboss.messaging.core.impl.message.MessageSupport.getPayload(MessageSupport.java:246)
       at org.jboss.jms.message.JBossStreamMessage.reset(JBossStreamMessage.java:656)
       at org.jboss.jms.message.JBossStreamMessage.doBeforeReceive(JBossStreamMessage.java:149)
       at org.jboss.jms.client.container.ClientConsumer$HandleMessageRunnable.run(ClientConsumer.java:904)
       at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
       at java.lang.Thread.run(Thread.java:595)


      I have added extra trace on my work copy, and when the test fails I could confirm the field is null.

      And the test was fixed by patching this:

      Index: jmx/src/main/org/jboss/mx/loading/RepositoryClassLoader.java
      ===================================================================
      --- jmx/src/main/org/jboss/mx/loading/RepositoryClassLoader.java (revision 68148)
      +++ jmx/src/main/org/jboss/mx/loading/RepositoryClassLoader.java (working copy)
      @@ -620,7 +620,7 @@
       throw new ClassNotFoundException("Class Not Found(blacklist): " + name);
       }
      
      - Translator translator = repository.getTranslator();
      + Translator translator = repository==null ? null : repository.getTranslator();
       if (translator != null)
       {
       // Obtain the transformed class bytecode
      
      


      I already have an issue on the EAP project, and I will commit the change there... but I want someone to validate it (please):

      http://jira.jboss.com/jira/browse/JBPAPP-420
      http://jira.jboss.com/jira/browse/JBAS-5071



        • 1. Re: RepositoryClassLoader::repository Null
          Scott Stark Master

          This should not be valid. There has to be a race condition that has destroyed the class loader that this thread has a hold of. All this is doing is allowing the parent class loader to be used during this transient period. Maybe that provides a more graceful failure, but it does not address the real problem.

          • 2. Re: RepositoryClassLoader::repository Null
            Adrian Brock Master

             

            "clebert.suconic@jboss.com" wrote:

            And the test was fixed by patching this:

            Index: jmx/src/main/org/jboss/mx/loading/RepositoryClassLoader.java
            ===================================================================
            --- jmx/src/main/org/jboss/mx/loading/RepositoryClassLoader.java (revision 68148)
            +++ jmx/src/main/org/jboss/mx/loading/RepositoryClassLoader.java (working copy)
            @@ -620,7 +620,7 @@
             throw new ClassNotFoundException("Class Not Found(blacklist): " + name);
             }
            
            - Translator translator = repository.getTranslator();
            + Translator translator = repository==null ? null : repository.getTranslator();
             if (translator != null)
             {
             // Obtain the transformed class bytecode
            
            


            I already have an issue on the EAP project, and I will commit the change there... but I want someone to validate it (please):

            http://jira.jboss.com/jira/browse/JBPAPP-420
            http://jira.jboss.com/jira/browse/JBAS-5071



            The correct fix is
             if (repository == null)
             throw new IllegalStateException("Use of undeployed classloader");
             Translator translator = repository.getTranslator();
            


            As Scott says, the real issue is elsewhere.
            It's also likely a memory leak.

            • 3. Re: RepositoryClassLoader::repository Null
              Clebert Suconic Master

               

              "Adrian" wrote:
              As Scott says, the real issue is elsewhere.
              It's also likely a memory leak.


              Yes... we have Executors.. I will have to clean up Executors ContextClassLoaders in our side