directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope (JIRA)" <>
Subject [jira] Commented: (DIRSERVER-796) LdapDn.toString() doesn't return valid parseable DN string
Date Wed, 13 Dec 2006 04:00:22 GMT
    [ ] 
Norval Hope commented on DIRSERVER-796:

Email thread relating to this issue:

 from  Norval Hope <>    hide details  10:29 am (4 hours ago)  
 to  Apache Directory Developers List <> 

I have a question regarding what to me seems to be a problem with
Rdn.tostring() and LdapDN.toString(), in that when quoted text is
passed in they return text which is no longer quoted. This is
problematic for me as there are cases in my code where I'm dealing
with either a Sun LdapName or an LdapDN and I expect just to be able
to do a toString() and end up with a valid DN.

Here is an example of what I mean:



import javax.naming.ldap.LdapName;
import javax.naming.InvalidNameException;

public class LdapNameTest
   public static void main(String[] args)
           LdapName        name = new LdapName("ou=a\\,comma,o=acme");
           LdapDN          dn = new LdapDN("oU=a\\,comma,O=acme");

           System.out.println("name='" + name.toString() + '\'');
           System.out.println("dn='" + dn.toString() + '\'');
           System.out.println("dn(up)='" + dn.getUpName() + '\'');
       catch (InvalidNameException e)
which produces this output


Now, I would have expected that LdapDN.toString() would have
guaranteed that code like this would work (even though some
information about the exact case of some characters in the original DN
would be lost):

  LdapDN mydn = new LdapDN(new LdapDN("oU=a\\,comma,O=acme").toString());

but as things stand this code would fail with a parsing exception
because the '\' has been thrown away. Hence only the .getUpName() call
returns a valid DN string.
I would have expected dn= to be as follows above:


where the attribute names have been normalized but we still have a
valid DN string.

from  Emmanuel Lecharny <>
     to  Apache Directory Developers List <> 

Well, LdapDN.toString() contract may be not really clear. It returns the
normalized name, which is not what you expect, but which is what the
server is using when doing DN comparizon, for speed sake. Let's say that
'toString' is not exactly the best name for this method, and we should
use toNormName() instead (this metho exists, but calculate the
normalized name).

Ok,ok, you are right, this is messy... :(

I suggest you open an issue, and make a proposal for methods renaming.
At least, we won't forget to do that during the next release race.

PS: LdapDN was not intended to be used in external tools, it was written
with performance in mind, because DN parsing and manipulation cost
around 50% of all the CPU when adding or searching data. However, this
was not really a reason to deliver such a crappy API :(

from  Norval Hope <>  
 to   Apache Directory Developers List <>, 

Thanks for the feedback. My point is that getNormName() should also
return a valid parseable DN string (with quoted chars). This won't
effect speed in comparisons or the general principal of having a
normalized representation.

> LdapDn.toString() doesn't return valid parseable DN string
> ----------------------------------------------------------
>                 Key: DIRSERVER-796
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: ldap
>    Affects Versions: 1.5.0, 1.0
>            Reporter: Norval Hope
> If you do the following:
>     LdapDN  dn = new LdapDN("oU=a\\,comma,O=acme");
> then you get the following
>     1. dn.toString() = dn.getNormName()        = 'ou=a,comma,o=acme'
>     2. dn.getUpName()                                        = 'oU=a\,comma,O=acme'
> Due to the value returned in 1. the following results in a parsing exception
>    LdapDN  dn = new LdapDN(new LdapDN("oU=a\\,comma,O=acme").getNormName());  
> I think the value in 1. should still be a valid parseable DN string instead, namely 'ou=a\,comma,o=acme'

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message