Bug 42449

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.