> >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?
Yep - I thought I'd explained it ok, but clearly not. Anyhow this is exactly the problem. Thread.getContextClassLoader() will typically return either "null" or the System classloader unless the application code explicitly overrides this by using setContextClassLoader on every thread it creates. Either of these cases will definitely cause problems in a dynamic server environment where the Xerces JAR is not necessarily on the system classpath e.g. where it's part of a custom class loading strategy. My suggestion would be twofold: (i) if getContextClassLoader returns null, then try class.getClassLoader() (ii) if getContextClassLoader returns a non-null value, but a ClassNotFound or NoClassDef exception is thrown when attempting to instantiate using the classloader from (i) then try using class.getClassLoader() I think that would support most cases of both standard classpath usage, and catch cases where dynamic classloaders are used (e.g. in servers). TIA -- Rob Walker 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]
