Which version of jboss are you using?
I don't know which classloader
VersionHelper12.loadClass() will use.
Try printing out:
it is probably one of these.
Thank you for replying. I'm running the JBoss 2.4.4 / Tomcat 3.2.3 bundle on SuSE Linux.
It appears that the VersionHelper12.class has package scope so printing it wont be possible... I'm under the impression that a class inherits the classloader from the thread instance it is running in, and I don't see why this class should override this.
What I tried also, was to do a simple Class.forName() construct with and without supplying a class loader as the third argument. The class loader I supplied was Thread.currentThread().getContextClassLoader. Both didn't produce errors...
Any other pieces of wisdom you can throw in ?
(I'm going to try using another factory class and see what happens).
Class.forName(String) loads from the classloader
of the calling class.
Your MBean is loaded through the MLet so you won't
see a problem.
I've got java 1.4 which includes the ldap stuff in
the jre so I can't really try this myself.
Hmmm... You speak of MLET's as though I should consider them. From my point of view the MLETs are "just" loaded to bootstrap JBoss and to load all jars in lib/ext onto the JBoss classpath. What I can't understand is why the classes that comprise the MBean loads from a different classpath that the MBean it self.
By the way. I tested my MBean with the JBoss 2.4.8/Tomcat 4.0.10 bundle - same problems... :-(
I mentioned the MLet because that is what loads
your MBean so class.forName() will use.
This is probably not true for Sun's class.
I don't know why Sun's class isn't using the
context classloader or looking at the classpath.
I do know this will work with JBoss3.0 because of
the UnifiedClassLoader system.
OK thank you.
I tried with JBoss 3.0 and it worked the first time. I'll escalate internally and ask that we wait to implement this feature untill we upgrade to JBoss 3.0.