You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Enrique Rodriguez (JIRA)" <di...@incubator.apache.org> on 2005/10/26 21:53:56 UTC
[jira] Created: (DIREVE-295) DirContext.search() with null Name results in NPE
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
Assigned to: Alex Karasulu
Priority: Minor
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 );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DIREVE-295) DirContext.search() with null Name results in NPE
Posted by "Alex Karasulu (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIREVE-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(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.
> 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.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 );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DIRSERVER-468) DirContext.search() with null Name
results in NPE
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRSERVER-468.
---------------------------------------
> DirContext.search() with null Name results in NPE
> -------------------------------------------------
>
> Key: DIRSERVER-468
> URL: https://issues.apache.org/jira/browse/DIRSERVER-468
> Project: Directory ApacheDS
> Issue Type: Improvement
> Reporter: Enrique Rodriguez
> Assignee: Alex Karasulu
> Priority: Minor
>
> 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 );
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.