LDAP-167: DefaultDirContextValidator errors with default empty base

[spring-projects-issues]

Marius Scurtescu(Migrated from LDAP-167) said:

Using a plain DefaultDirContextValidator results in errors, with both Active Directory and Sun Directory Server. As soon as a valid base DN is set it works as expected.

First a warning is logged:
14:05:50,355 WARN [DefaultDirContextValidator] DirContext ‘javax.naming.ldap.InitialLdapContext@799f9a’ failed validation with an exception.
javax.naming.NameNotFoundException: [LDAP: error code 32 – 0000208D: NameErr: DSID-031001A8, problem 2001 (NO_OBJECT), data 0, best match of:
‘’
]; remaining name ’’
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3010)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1808)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1731)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
at org.springframework.ldap.pool.validation.DefaultDirContextValidator.validateDirContext(DefaultDirContextValidator.java:154)
at org.springframework.ldap.pool.factory.DirContextPoolableObjectFactory.validateObject(DirContextPoolableObjectFactory.java:169)
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1035)
at org.springframework.ldap.pool.factory.PoolingContextSource.getContext(PoolingContextSource.java:394)
at org.springframework.ldap.pool.factory.PoolingContextSource.getReadOnlyContext(PoolingContextSource.java:374)
at org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:770)
at org.springframework.ldap.core.LdapTemplate.lookup(LdapTemplate.java:897)
[…]

then an error:
14:05:50,358 ERROR [SequentialChannelRunner] Channel run error! Channel: channel1
org.springframework.dao.DataAccessResourceFailureException: Failed to borrow DirContext from pool.; nested exception is java.util.NoSuchElementException: Could not create a validated object
at org.springframework.ldap.pool.factory.PoolingContextSource.getContext(PoolingContextSource.java:397)
at org.springframework.ldap.pool.factory.PoolingContextSource.getReadOnlyContext(PoolingContextSource.java:374)
at org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:770)
at org.springframework.ldap.core.LdapTemplate.lookup(LdapTemplate.java:897)
[…]
Caused by: java.util.NoSuchElementException: Could not create a validated object
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1049)
at org.springframework.ldap.pool.factory.PoolingContextSource.getContext(PoolingContextSource.java:394)
… 9 more

[spring-projects-issues]

Mattias Hellborg Arthursson said:

Yes this behavior changed in the 1.3 version of Spring LDAP. LdapTemplate would previously silently ignore any NameNotFoundException encountered during a search; in this version we decided this behavior is actually not correct. Thinking more closely about this, it’s kind of similar to performing a SQL select against an invalid table.

I realize it’s a nuisance having to change a setup that was previously working, but I would like to argue that this is actually an accurate behavior.

[spring-projects-issues]

Marius Scurtescu said:

Well, the fact that NameNotFoundException is not ignored is a good thing IMO, and it was not the reason I opened this issue.

The reason I created this issue is because DefaultDirContextValidator is not working out of the box, and the reference documentation states that it should. This is from the reference doc:
bq. The DefaultDirContextValidator should work with no configuration changes on most LDAP servers and provide the fastest way to validate the DirContext .

I can see two different solutions here:
1. Accept that a base DN is needed. Ref docs would need to reflect that, and ideally the constructor should require that, so you are forced to provide one.
2. Change the implementation so it really works with no configuration changes.

That being said, it is possible that the actual implementation of DefaultDirContextValidator is fine and the problem is somewhere else. The following code, very similar to the implementation of DefaultDirContextValidator, works fine for me:

        List result = search(
                "",
                "(objectclass=*)",
                SearchControls.OBJECT_SCOPE,
                new String[] {"supportedControl"},
                new AbstractContextMapper()
                {
                    protected Object doMapFromContext(DirContextOperations ctx)
                    {
                        Set<String> controlsSet = new HashSet<String>();

```
                    controlsSet.addAll(Arrays.asList(ctx.getStringAttributes("supportedControl")));

                    return controlsSet;
                \}
            \}
    );
```

The only difference that jumps out at me is the actual attribute that is retrieved (objectclass vs supportedControl).

I will do some more testing.
bc..

[spring-projects-issues]

Ulrik Sandberg said:

Could this be related to LDAP-189? That bug causes search scope to always be ONELEVEL_SCOPE. LDAP-189 has been fixed, so perhaps you could test it again using code from trunk?

[spring-projects-issues]

Ulrik Sandberg said:

Possibly caused by that issue.

[spring-projects-issues]

Ulrik Sandberg said:

Don't know enough to go further with this. Might be caused by a related issue.

[spring-projects-issues]

Edward Sutter said:

I ran into this exact issue and we were running 1.3.0 of Spring LDAP. Upgrading to 1.3.1 resolved it. This is the same version that LDAP-189 was resolved in so it may be related.

[spring-projects-issues]

This issue is related to #228