You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/01/17 00:24:44 UTC
DO NOT REPLY [Bug 16189] New: -
Tomcat Hangs in SSL Mode (Both 4.1.18 and 4.1.18LE for JDK 1.4)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16189>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16189
Tomcat Hangs in SSL Mode (Both 4.1.18 and 4.1.18LE for JDK 1.4)
Summary: Tomcat Hangs in SSL Mode (Both 4.1.18 and 4.1.18LE for
JDK 1.4)
Product: Tomcat 4
Version: 4.1.18
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: steve@crmsoftware.com.au
Spec.
Tomcat 4.1.18LE for JDK 1.4 (Problems also occurs with standard 4.1.18)
Struts 1.1-beta2
JDK 1.4.1
Win2k
Intermittent problem. After some use the following error occurs.
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Jdk14Logger does not implement
....
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Jdk14Logger does not implement Log
....
Caused by: org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Jdk14Logger does not implement Log
The Container hangs and needs to be restarted. This genereally happens within
the first few actions that are called.
When SSL links/forms etc. are removed from my app, this problem does not occur.
Thinking it would help, have switched from Log4j to JDK 1.4 Logging
have also tried comment out <Logger> Tags in server.sml so that logging goes to
the console.
Problem still occurs
Regards
Steve Vanspall
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Return of the CL bug
Posted by Remy Maucherat <re...@apache.org>.
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.
Actually, the problem was that the "bin" directory was set as endorsed,
and one JAR in there was including a lot of things that didn't belong.
Nasty bug to spot ;-)
This should fix all the commons-logging CL failures users have been
reporting (I think).
> 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.
With only the XML parser in there, I don't think it creates problems. If
the user tries to use it, there could be problems, that's true ;-) It's
a bit like allowing users to change the system classpath, actually.
BTW, I'm having issues with your latest change to the main build.xml (it
fails trying to build Coyote).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] Return of the CL bug
Posted by Jeanfrancois Arcand <jf...@apache.org>.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
Re: [5.0] Return of the CL bug
Posted by Costin Manolache <cm...@yahoo.com>.
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.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[5.0] Return of the CL bug
Posted by Remy Maucherat <re...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>