Rob Walker wrote: > > 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).
Sorry to be late in the discussion. The proposed fix may not solve your problem starting w/ JDK 1.4.0. The reason is that the code you refer to or versions like it are part of the JDK platform and are loaded by the bootstrap CL. This means that the current CL will be the bootstrap CL and will not see your impl unless it is on the bootstrap classpath. -Edwin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
