DirContext.search() with null Name results in NPE

• Key: DIRSERVER-468
• Type: Improvement
• Status: Closed
• Resolution: Won't Fix
• Priority: Minor
• Assignee: Alex Karasulu
• Reporter: Enrique Rodriguez

Description

This is a minor issue I am marking as an improvement since the JNDI API doesn't appear to say explicitly what the behavior is, so I'm entering this issue to document it. The issue is that if you supply a null Name as the name to search in DirContext.search() you get a NPE. If you supply a null String, however, it is treated as the empty String, which indicates a search at the current context's name. IMO, a null Name should be treated like the empty String.

So, a null Name fails with NPE:

        Name name = null;
        NamingEnumeration answer = ctx.search( name, matchAttrs, attrIDs );

java.lang.NullPointerException
at org.apache.ldap.common.name.LdapName.addAll(LdapName.java:527)
at org.apache.ldap.server.jndi.ServerContext.buildTarget(ServerContext.java:843)
at org.apache.ldap.server.jndi.ServerDirContext.search(ServerDirContext.java:488)
...

But, a null String will work fine:

        String name = null;
        NamingEnumeration answer = ctx.search( name, matchAttrs, attrIDs );

Which is the same as the empty String, which works fine, too;

        String name = "";
        NamingEnumeration answer = ctx.search( name, matchAttrs, attrIDs );

Comments

[Alex Karasulu]

Hi Enrique,

I did not know the answer to this so I tested it with the SUN JNDI LDAP provider using this code here:

    public void testNullNameToCtxSearch() throws NamingException
    {
        final Hashtable env = new Hashtable();

        env.put( Context.PROVIDER_URL, "ldap://localhost:" + port + "/dc=aPache,dc=org" );
        env.put("java.naming.ldap.version", "3");
        env.put( Context.SECURITY_PRINCIPAL, "uid=admin,ou=system" );
        env.put( Context.SECURITY_CREDENTIALS, "secret" );
        env.put( Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory" );
        InitialDirContext ctx = new InitialDirContext( env );
        Name nullName = null;
        ctx.search( nullName, "(objectClass=*)", new SearchControls() );
    }

Here's the NPE I got from the NamingSubsystem:

java.lang.NullPointerException
at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:330)
at javax.naming.directory.InitialDirContext.getURLOrDefaultInitDirCtx(InitialDirContext.java:99)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:245)
at org.apache.ldap.server.MiscTest.testNullNameToCtxSearch(MiscTest.java:328)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:31)

Just to double check I tested handing off null to our provider to look at the stack trace:

java.lang.NullPointerException
at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:330)
at javax.naming.directory.InitialDirContext.getURLOrDefaultInitDirCtx(InitialDirContext.java:99)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:245)
at org.apache.ldap.server.MiscTest.testBogusAttributeInSearchFilter(MiscTest.java:316)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:31)

The same exact trace due to IDC wrapper. If IDC behaves this way I think its ok for our contexts to behave in the same manner.