Apologies if this is a common question that you guys are sick of answering!
We use Xerces in an OSGi environment, where various dynamic classloaders
are created to handle loading of classes related to specific service modules
(actually termed "bundles" under OSGi).
Because of this, the Xerces JAR is not typically loaded from the System
classloader. This causes us problems when we instantiate a SAX Parser, which
seems to use Thread.getCurrentContextClassloader() to determine the
classloader to use to find and instantiate it's various classes. Typically this
method returns the System classloader if not specifically set by the thread in
question.
To date, we've gotten around this by adding the following to the the run()
method
of any threads we create:
setContextClassLoader(this.getClass().getClassLoader());
This is starting to become a pain though. Is there some reason that Xerces
looks
for it's thread's classloader in this way? And also, is there some neater, more
generic way we can get around this?
TIA
-- Rob
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
