I have recently upgraded our development system from 4.1.24 to 4.1.27 and
noticed some new problems.

The first is just a warning (I think) and so is not critical, but the second is
more fundamental.

We currently use JDK1.3.1 (with Suns' JSSE added as an installed extension) and
when I start Tomcat 4.1.27 we get lots of SSL (peer not authenticated) errors
(our app uses SSL throughout), which we don't get in 4.1.24.

[WARN] Http11Processor - -Exception getting SSL attributes
<javax.net.ssl.SSLPeerUnverifiedException: peer not
authenticated>javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
     at
com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificateChain([DashoPro-V1.2-120198])

     at
org.apache.tomcat.util.net.jsse.JSSESupport.getX509Certificates(JSSESupport.java:113)

     at
org.apache.tomcat.util.net.jsse.JSSESupport.getPeerCertificateChain(JSSESupport.java:161)

     at
org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:748)
     at org.apache.coyote.Response.action(Response.java:222)
     at
org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:321)
     at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:221)
     at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:601)
     at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)

     at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
     at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)

     at java.lang.Thread.run(Thread.java:479)

If we switch to JDK1.4.1, we don't get these.  There was a bug in bugzilla about
this, but it was supposedly fixed in 4.1.12 (and I hadn't seen it in ages), was
it re-introduced somehow?

Secondly, and more importantly, occasionally, when running through the
application, we get the following:

[ERROR] Http11Protocol - -Error reading request, ignored
<org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.SimpleLog does not implement
Log>org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.SimpleLog does not implement Log
     at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:532)

     at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272)

     at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:246)

     at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)
     at org.apache.tomcat.util.net.jsse.JSSESupport.<init>(JSSESupport.java:87)
     at
org.apache.tomcat.util.net.jsse.JSSE13Factory.getSSLSupport(JSSE13Factory.java:84)

     at
org.apache.tomcat.util.net.jsse.JSSEImplementation.getSSLSupport(JSSEImplementation.java:118)
     at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:385)

     at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
     at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)

     at java.lang.Thread.run(Thread.java:479)

There is an equivalent if we run with JDK1.4 but it complains about the JDK14
logger instead (and the error is SEVERE).  But both loggers blatantly do
implement the Log interface, so what's getting confused?

The app in question is a struts application using struts 1.1 final (which
includes the commons-logging.jar) but Tomcat has its own copy of commons-logging
(I think our application one is the same version, it's the same size as
tomcat's), so are they getting mixed up somehow? Once this happens (it's not
predicable, it just seems to happen sometimes) the whole application locks up
and I can't do any requests to the SSL port (to any application including the
Tomcat manager app). The non-SSL port seems to be ok, and I can shutdown/restart
the application using that, but what is up with my SSL connection?

Thanks,

Daniel


 Tertio Telecoms Limited  -  One Angel Square,   Torrens Street,   London  EC1V
1PL
Tel: +44 (0)20 7843 4000 Fax: +44 (0)20 7843 4001 Web http://www.tertio.com
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of Tertio Ltd.



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

Reply via email to