You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Norval Hope <nr...@gmail.com> on 2006/12/13 00:29:44 UTC

Current Rdn/LdapDN behaviour

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:

==== LdapNameTest.java

import org.apache.directory.shared.ldap.name.LdapDN;

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

Re: Current Rdn/LdapDN behaviour

Posted by Norval Hope <nr...@gmail.com>.
On 12/13/06, Emmanuel Lecharny <el...@gmail.com> wrote:> 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 :(
>
> Emmanuel
>

Thanks for the feedback. My point is that toNormName() 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.

I'll open a JIRA with this thread included.

Re: Current Rdn/LdapDN behaviour

Posted by Emmanuel Lecharny <el...@gmail.com>.
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:
>
> ==== LdapNameTest.java
>
> import org.apache.directory.shared.ldap.name.LdapDN;
>
> 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 :(

Emmanuel