directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Current Rdn/LdapDN behaviour
Date Wed, 13 Dec 2006 02:09:47 GMT
Norval Hope a écrit :

> Firstly let me apologise for going silent of late: combination of
> having to support an alpha release and some personal tragedies. I
> still intend to write the VD schema related blurb I promised in the
> next couple of weeks...
> 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;
> import javax.naming.ldap.LdapName;
> import javax.naming.InvalidNameException;
> public class LdapNameTest
> {
>    public static void main(String[] args)
>    {
>        try
>        {
>            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)
>        {
>            e.printStackTrace();
>        }
>    }
> }
> ====
> which produces this output
> name='ou=a\,comma,o=acme'
> dn='ou=a,comma,o=acme'
> dn(up)='oU=a\,comma,O=acme'
> 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:
> dn='ou=a\,comma,o=acme'
> where the attribute names have been normalized but we still have a
> valid DN string.
> Am I missing something here, or should I open a JIRA about this?
> Thanks
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 :(


View raw message