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 2007/05/17 22:52:04 UTC

DO NOT REPLY [Bug 42449] New: - JNDIRealm does not catch NullPointerException

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42449>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42449

           Summary: JNDIRealm does not catch NullPointerException
           Product: Tomcat 6
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: nvick@capcollege.bc.ca


We have found in production that the JNDIRealm can get to a point where
NullPointerExeception's are thrown by Sun's LDAP provider for JNDI, and no user
can log in. It seems that Sun's LDAP provider holds onto its SSL connection to
our Novell LDAP server, even after it throws a NullPointerException. 

The JNDIRealm does not catch NullPointerExceptions, so it does not close the
JNDI context or retry. However, we have found that if we change the two catch
clauses in the "authenticate(String username, String credentials)" method to
catch Exception (which includes NullPointerException), then the problem goes away.

Tomcat 6.0.13:
811:            } catch (CommunicationException e) {
835:        } catch (NamingException e) {

Our hack:
811:            } catch (Exception e) {
835:        } catch (Exception e) {

The only drawback we have found in changing the first catch clause to Exception
is that all exceptions cause a retry, including incorrect username/password
attempts. It might be possible to avoid these unnecessary retries by checking
for AuthenticationException. Another approach might be to add an option to
always the close JNDI context before authenticating, if the performance is
acceptable. 

At the very least, changing the outer catch clause to Exception means that after
the LDAP connection goes bad, only the first user to try logging in will see an
error. Subsequent login attempt should succeed because the outer catch clause
will catch the NullPointerException from the first failed login attempt and
close the JNDI context.

NOTE: we use the "Bind mode" option of JNDIRealm, and we have been using JDK
1.5.0_06 on Red Hat Enterprise Linux 4.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


DO NOT REPLY [Bug 42449] - JNDIRealm does not catch NullPointerException

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42449>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42449


funkman@joedog.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From funkman@joedog.org  2007-05-20 11:33 -------
fixed with
Committed revision 539907.

thanks!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org