RepositoryClassLoader::repository Null

[clebert.suconic]

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

[starksm64]

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.

[adrian.brock]

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.

[clebert.suconic]

"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