You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Stefan Seelmann (JIRA)" <ji...@apache.org> on 2008/06/11 16:58:46 UTC

[jira] Closed: (DIRSHARED-3) Rdn.compareTo() method is not invertable

     [ https://issues.apache.org/jira/browse/DIRSHARED-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Seelmann closed DIRSHARED-3.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 0.9.12

Fixed in trunk and bigbang:
  http://svn.apache.org/viewvc?rev=666691&view=rev
  http://svn.apache.org/viewvc?rev=666692&view=rev


> Rdn.compareTo() method is not invertable
> ----------------------------------------
>
>                 Key: DIRSHARED-3
>                 URL: https://issues.apache.org/jira/browse/DIRSHARED-3
>             Project: Directory Shared
>          Issue Type: Bug
>    Affects Versions: 0.9.10
>            Reporter: Stefan Seelmann
>            Assignee: Stefan Seelmann
>            Priority: Minor
>             Fix For: 0.9.11, 0.9.12
>
>
> The API doc of Comparable.compareTo() states:
> "The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y."
> I think the Rdn.compareTo() method doesn't fulfill this contract for some special multi-valued RDNs:
> Case1: mv-RDNs with same types but different values
> RDN1: a=b+a=c
> RDN2: a=b+a=y
> Case2: mv-RDNs with complete different types
> RDN1: a=b+c=d
> RDN2: e=f+g=h
> In both cases RDN1.compareTo(RDN2) returns 1 and also RDN1.compareTo(RDN2) returns 1, but it must be something like 1 and -1.
> BTW: Why does the LDAP/X.500 spec allows such mv-RDNs? Grrrr

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.