I see nine bugs out there for JNDIRealm for tomat 4 and 5, included is the one mentioned below in the previous email.
http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Tomcat+4&product=Tomcat+5&short_desc=jndirealm&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Reuse+same+sort+as+last+time
I have used JNDIRealm in the past but stopped using it in favor of other solutions for unrelated reasons.
Can you do me a favor? If you are able, can you update the bugs above and send me a patch for the stuff below (and any applicable bugs above) and I'll try to get 'em in next week.
-Tim
Jeff Tulley wrote:
Something from the user list of note for development.
The current method does something like this when handling a
communication exception at authenticate time:
/ If not a "Socket closed." error then rethrow.
if (e.getMessage().indexOf("Socket closed") < 0) throw(e);
This seems to have two problems 1) e.getMessage() is sometimes null with some LDAP providers. 2) some LDAP providers set the exception to actually be "connection closed" (retrieved by "e.toString()")
Just forwarding this on for the user, since this code currently has some problems that ought to be fixed. (I have a vested interest being a heavy user of JNDIRealm).
For a stopgap measure, one could do the following I guess: if (e.toString().indexOf("closed") < 0) throw(e); Though as the bug report points out there may be yet other error messages given by other LDAP providers, and I don't know if "closed" is too general to check on or not.
Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com
[EMAIL PROTECTED] 8/1/03 2:00:46 PM >>>
Well, I understand this is now a bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19864
Was this fixed in the 4.1.27 version? Can't seem to determine if it was
based on the README in the download.
Jon
On Friday, August 1, 2003, at 12:07 PM, Jon Wynacht wrote:
Hi,
I have Tomcat 4.1.24 installed on a server that hosts a web application. I have set up the container to do authentication via
LDAP
and it works for a bit then just stops working. The only way to get
things working again is to restart Tomcat.
I've included the error message below and am wondering if anybody on
this list has had a similar experience? If so, how did you solve it?
Thanks in advance,
Jon
2003-08-01 10:37:29 JNDIRealm[Standalone]: lookupUser(jwynacht)
2003-08-01 10:37:29 JNDIRealm[Standalone]: dn=uid=jwynacht, ou=active, ou=employees, ou=people, o=cisco.com
2003-08-01 10:37:29 JNDIRealm[Standalone]: validating credentials
by
binding as the user 2003-08-01 10:37:29 JNDIRealm[Standalone]: binding as uid=jwynacht,
ou=active, ou=employees, ou=people, o=cisco.com
2003-08-01 10:37:29 CoyoteAdapter An exception or error occurred in
the container during the request processing
java.lang.NullPointerException
at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:793)
at
org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Basic
Authenticator.java:161)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticato
rBase.java:526)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24
15)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav
a:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV
alve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav
a:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve
.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:5
94)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process
Connection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:5
65)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPoo
l.java:619) at java.lang.Thread.run(Thread.java:536)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
