How to dynamically load jar files - limiting scope to that thread

Question

Dynamically loading jar files has been discussed a lot. I have read a quite a few posts, articles, and demo code for doing just that. However, I have yet to find a solution to my problem. Most people modify their system class loader and are happy. I have done that and was happy for a time. Occasionally, you will see reference to an application server or tomcat or some other large project that have successfully been able to load and unload jar files, allow for dynamic deployment of code, etc. However, I have not been able to achieve similar success; And my problem is much less complicated.
I have an application that executes a thread to send a given file/message to a standard JMS Server Queue. Depending on the parameters selected by the user, this thread may need to communicate with one of a number of JMS Servers, ie. JBoss, WebLogic, EAServer, Glassfish, etc. All of which can be done with the same code, but each needs to load their own flavor of JMS Client Jar files. In this instance, spawning a separate JVM for each communication would work from a classloader perspective. However, I need to keep it in the family and run under the same JVM, albeit each JMS Server Connection will be created and maintained in separate Threads.
I am close, I am doing the following...
1. Creating a new URLClassLoader in the run() method of each thread.
2. Set this threads contextClassLoader to the new URLClassLoader.
3. Load the javax.jms.JMSException class with the URLClassLoader.loadClass() method.
4. Create an initialContext object within this thread.
Note: I read that the initialContext and subsequent conext lookup calls would use the Thread�s
contextClassLoader for finding/loading classes.
5. Perform context.lookup calls for a connectionFactory and Queue name.
6. Create JMS Connection, etc. Send Message.
Most of this seems to work. However, I am still getting a NoClassDefFoundError exception for the javax.jms.JMSException class ( Note step #3 - tried to cure unsuccessfully).
If I include one of the JMS Client jar files ( ie wljmsclient.jar for weblogic ) in the classpath then it works for all the different JMS Servers, but I do not have confidence that each of the providers implemented these classes that now resolve the same way. It may work for now, but, I believe I am just lucky.
Can anyone shine some light on this for me and all the others who have wanted to dynamically load classes/jar files on a per Thread basis?

Answer 1

Thanks to everyone - I got it working!
First, BenSchulz' s dumpClassLoader() method helped me to visualize the classLoader hierarchy. I am still not completely sure I understand why my initial class was always found by the systemClassLoader, but knowning that - was the step I needed to find the solution.
Second, kdgregory suggested that I use a "glue class". I thought that I already was using a "glue class" because I did not have any JMSClient specific classes exposed to the rest of the application. They were all handled by my QueueAdmin class. However...
The real problem turned out to be that my two isolating classes (the parent "MessageSender", and the child "QueueAdmin") were contained within the same jar file that was included in the classpath. This meant that no matter what I did the classes were loaded by the systemClassLoader. Isolating them in classes was just the first step. I had to remove them from my jar file and create another jar file just for those JMSClient specific classes. Then this jar file was only included int custom classLoader that I created when I wanted to instantiate a JMSClient session.
I had to create an interface in the primary jar file that could be loaded by the systemClassLoader to provide the stubs for the individual methods that I needed to call in the MessageSender/QueueAdmin Classes. These JMSClient specific classes had to implement the interface so as to provide a relationship between the systemClassLoader classes and the custom classLoader classes.
Finally, when I loaded and instantiated the JMSClient specific classes with the custom classLoader I had to cast them to the interface class in order to make the method calls necessary to send the messages to the individual JMS Servers.
psuedu code/concept ....
Primary Jar File   -  Included in ClassPath                                                      
Class<?> cls = ClassLoader.loadClass( "JMSClient.MessageSender" )
JMSClientInterface jmsClient = (JMSClientInterface) cls.newInstance()                            
jmsClient.sendMessage()                                                                      
JMSClient Jar File  -  Loaded by Custom ClassLoader Only
MessageSender impliments Primary.JMSClientInterface{
    sendMessage() {
        Class<?> cls=ClassLoader.loadClass( "JMSClient.QueueAdmin" )
        QueueAdmin queueAdmin=(QueueAdmin) cls.newInstance()
        queueAdmin.JMSClientSpecificMethod()
    }