[ http://issues.apache.org/jira/browse/DIRSERVER-796?page=comments#action_12458012 ] Norval Hope commented on DIRSERVER-796: ---------------------------------------
Email thread relating to this issue: ========= from Norval Hope <[EMAIL PROTECTED]> hide details 10:29 am (4 hours ago) to Apache Directory Developers List <[email protected]> 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. ==== from Emmanuel Lecharny <[EMAIL PROTECTED]> to Apache Directory Developers List <[email protected]> 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 <[EMAIL PROTECTED]> to Apache Directory Developers List <[email protected]>, 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: http://issues.apache.org/jira/browse/DIRSERVER-796 > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
