I've been digging into the classloader for the last two days, and have refined my classloading questions from my big one on recursive invocation to several smaller ones. I'm using a scoped SAR to deploy an MBean. My SAR has a classpath entry pointing to file://myDir; I do not have a classpath entry for the server lib directory. Suppose I have the following JARs:

/jboss/server/default/lib
------------------------
myThread.jar
myException.jar
bsh2.jar

/myDir
------------------------
bsh1.jar

(1) I'm using the Debug class to explore classloading. From one of the top-level methods in my MBean, I display both getClass().getClassLoader() and Thread.currentThread().getContextClassLoader(). The first shows my SAR, as I would expect. However, the second shows null, meaning the bootstrap classloader. I didn't expect that - thought they would be the same. Why are they different?

(2) My MBean method instantiates an extends-Thread class from myThread.jar. I notice myThreadObj uses the startup classloader and not my SAR classloader. I'm guessing this is because myThread.jar is in server/default/lib, which is not scoped by my SAR, correct?

(3) After the MBean instantiates myThreadObj, it does myThreadObj.setContextClassLoader(getClass().getClassLoader()) - see (1) above. I verified that myThreadObj, in the run() method, does indeed have the SAR's classloader by printing out Thread.currentThread().getContextClassLoader(). However, in that run() method, when I instantiate a bsh object, it's using the startup classloader and not my SAR classloader. I end up with a bsh2 object instead of the bsh1 object I need. I didn't expect that at all. Again, I'm thinking this is because, per (3) above, since myThreadObj uses the startup classloader, when it needs to instantiate an object, it checks its own classloader and finds bsh2.jar there. Correct? If so, then when does the context classloader get used?

(4) I moved myThread.jar into /myDir, and I'm now picking up bsh1.jar. The last problem I encountered was that since I was moving all my jars, I went ahead and moved myException.jar to /myDir also. myException.jar contains the exceptions that the MBean methods throw. When I started up JBoss and deployed my SAR, JBoss complained that it couldn't find the exception classes. So I had to put myException.jar back into server/default/lib, and now everything works. But why did this happen? Since the exception classes are only thrown by my MBean, shouldn't the deployer have been able to find them in /myDir? I guess I'm unclear about which classloader the deployer is using. It seems to be picking up all the other classes used by the MBean from /myDir, so why not the exception classes?

--
Guy Rouillier





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to