Previous | Next | Trail Map | Tips for LDAP Users | Frequently Asked Questions

Names

Why do I get an empty string as a name in my SearchResult(in the API reference documentation) ?

getName()(in the API reference documentation)always returns a name relative to the target context of the search. So, if the target context satisfies the search filter then the name returned will be "" (the empty name), because that is the name relative to the target context. See the Searches (in the Tips for LDAP Users trail) lesson for details.

Why do I get a URL string as a name in my SearchResult(in the API reference documentation) ?

The LDAP entry was retrieved by following either an alias or a referral, so its name is a URL. See the Searches (in the Tips for LDAP Users trail) lesson for details.

Is the Name(in the API reference documentation) argument to the Context(in the API reference documentation) and DirContext(in the API reference documentation) methods a CompoundName(in the API reference documentation) or a CompositeName(in the API reference documentation) ?

Both the string forms and Name of the Context and DirContext methods accept composite names. The string forms accept the string representation of a composite name, while the Name forms accept the CompositeName structure.

The name I got back from NameParser(in the API reference documentation) doesn't work with the Context(in the API reference documentation) methods. Why?

(This is related to the previous question.) The Context methods accept the composite names, and the result returned by NameParser is a compound name.

What's the relationship between the name I use for the Context.SECURITY_PRINCIPAL(in the API reference documentation) property and the directory?

You can think of the principal name as coming from a different namespace than the directory. See draft-ietf-ldapext-authmeth-03.txt and the Security (in the Tips for LDAP Users trail) lesson for details on LDAP authentication mechanisms. Sun's LDAP service provider accepts a string principal name, which it passes directly to the LDAP server. Some LDAP servers accept distingushished names, while others support the schemes proposed by draft-ietf-ldapext-authmeth-03.txt.

Why are there strange quotes and escapes in the names I read from the directory?

Sun's LDAP name parser is conservative with respect to quoting rules but nevertheless produces "correct" names. Also, remember that the names of entries returned by NamingEnumerations(in the API reference documentation) are composite names that can be passed back to the Context and DirContext methods. So, if the name contains a character that conflicts with the composite name syntax (such as the forward character "/"), the LDAP provider will provide an encoding to ensure that the slash will be treated as part of the LDAP name rather than as a composite name separator.

How do I get an LDAP entry's full distinguished name?

In the JNDI, all names are relative to a context. If you want an entry's full distinguished name, you need to keep track of its ancestors' names starting from the initial context. If there was a distinguished name specified in the Context.PROVIDER_URL(in the API reference documentation) property, then that needs to be inserted as the start of the distinguished name. See the Searches (in the Tips for LDAP Users trail) lesson for details.


Previous | Next | Trail Map | Tips for LDAP Users | Frequently Asked Questions