Re: [5.0] Return of the CL bug

[Jeanfrancois Arcand]

Costin Manolache wrote:

It won't happen in JDK1.3

It won't happen if you remove the "endorsed.dirs" from the CLI.

I think endorsed is completely broken, there are many other problems
and leads to undeterministic behavior. We should just remove it and
add it back in JDK1.5 or when it is fixed.

My +1 to remove the "endorsed". There is no need to use a different
version of javax.xml or org.w3c.dom or org.xml - and if someone needs
a different one, he can use JDK1.3 or file a bug report on Sun site.

How we will supports XML schema if we remove the endorsed directory? In 1.4, Crimson will be defaulted and Crimson doesn't supports schema :-(

-- Jeanfrancois

Costin



Remy Maucherat wrote:

This one looks similar to the CL problems with commons-logging (that I
don't get). If JK 2 is enabled, I get a CL error during its
initialization:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:262)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:395)
Caused by: java.lang.NoClassDefFoundError:
javax/management/MBeanRegistration
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at
java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:723)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at
java.lang.ClassLoader.loadClass(ClassLoader.java:292) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at
java.lang.ClassLoader.loadClass(ClassLoader.java:255) at

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:840)

at

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)

at

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:840)

at

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)

at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at

org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader.java:520)

at

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:857)

at

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)

at

org.apache.coyote.tomcat5.CoyoteConnector.initialize(CoyoteConnector.java:983)

at

org.apache.catalina.core.StandardService.initialize(StandardService.java:579)

at

org.apache.catalina.core.StandardServer.initialize(StandardServer.java:2347)

at org.apache.catalina.startup.Catalina.load(Catalina.java:503)
at org.apache.catalina.startup.Catalina.load(Catalina.java:521)
... 6 more

Somehow, if JMX is in endorsed, the error does not happen, as for some
odd reason, the CL thinks it is a good idea to look for the class in the
system classloader.
I did look very briefly at the problem, but can't find an explanation yet.

(like Costin, I hate classloaders)

Remy

--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>