The method Thread.getCurrentContextClassloader() gets around my class loader and causes problems.
I would prefer you to use Class.getClassLoader() to get the appropriate class loader.
Thanks, From Richard.
Andy Clark wrote:
Rob Walker wrote:
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
Which problems?
seems to use Thread.getCurrentContextClassloader() to determine the
classloader to use to find and instantiate it's various classes. Typically this
This is the prescribed way to dynamically load classes
in Java2 and is recommended over the typcially used method,
Class#getClassLoader.
There are a few cases where classes are dynamically loaded in Xerces2 (and for that matter Xerces 1.x as well). One place is JAXP. The factory classes are specified in a Jar service (META-INF/services) config file.
The same strategy is used within the Xerces2 ObjectFactory which is basically code borrowed from the JAXP internal factory and which is used to dynamically load the config that the parser classes should be using.
The problem I'm guessing that you are running into is that the Thread#getContextClassLoader is actually returning null in your environment. Typically, this should not happen but I guess there are probably reasons why it's implemented that way.
So from this perspective I can see the inherent problem. In this case, we should probably revert back to using Class#getClassLoader since we do need *some* class loader
in order to instantiate the objects we need. Have I hit
the cause of your problem?
This would require a change to the xml-commons JAXP code, the JAXP code in xml-xerces (copied from xml-commons but with modifications), *and* the ObjectFactory class since this was written from the JAXP code. Not too hard to do -- I just want to make sure that this would fix the problem you're experiencing before I commit any changes.
for it's thread's classloader in this way? And also, is there some neater, more
generic way we can get around this?
Not at the moment. We'd have to fix the code and then you'd have to actually use the version of Xerces incorporating those changes.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
