Guy Rouillier wrote:
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?
The MBeanServer sets the thread context class loader to the loader of the sar
deployment on each invocation. You will have to describe how this method is
being invoked. The calling context is responsible for setting the thread context
class loader.
(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?
The only classes that will be in the scoped repository are those explicitly
referenced by the sar or in the sar.
(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?
Correct. You have to explicitly use the thread context class loader loadClass
method to load classes from it.
(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?
Show the CNFE stacktrace for the exception case.
--
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
-------------------------------------------------------
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
