| Alex Karasulu (JIRA) 2005-10-28, 5:45 pm |
| [ http://issues.apache.org/jira/brows...VE-295?page=all ]
Alex Karasulu resolved DIREVE-295:
----------------------------------
Fix Version: 0.9.3
Resolution: Won't Fix
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(InitialDirCont
ext.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(InitialDirCont
ext.java:99)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:245)
at org.apache.ldap.server.MiscTest. testBogusAttributeInSearchFilter(MiscTes
t.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.
> DirContext.search() with null Name results in NPE
> -------------------------------------------------
>
> Key: DIREVE-295
> URL: http://issues.apache.org/jira/browse/DIREVE-295
> Project: Directory Server
> Type: Improvement
> Components: jndi-provider
> Reporter: Enrique Rodriguez
> Assignee: Alex Karasulu
> Priority: Minor
> Fix For: 0.9.3
>
> 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.se
arch() 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 );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|