directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] Commented: (DIRSHARED-3) Rdn.compareTo() method is not invertable
Date Mon, 12 May 2008 21:07:55 GMT


Emmanuel Lecharny commented on DIRSHARED-3:

There is potentially a third kind of error :

RDN1: a=b+c=d
RDN2: d=e+a=b

Assuming that the ATAVs are ordered internally using the 'natural order' (ie, lexicographic
for AttributeType), the RDN are compared without taking into account the user provided form.
So in the previous RDN, they are considered as :

RDN1: a=b+c=d
RDN2: a=b+d=e

Anyway, there is something we can do to fix this.

> Rdn.compareTo() method is not invertable
> ----------------------------------------
>                 Key: DIRSHARED-3
>                 URL:
>             Project: Directory Shared
>          Issue Type: Bug
>    Affects Versions: 0.9.10
>            Reporter: Stefan Seelmann
>            Priority: Minor
>             Fix For: 0.9.11
> The API doc of Comparable.compareTo() states:
> "The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and
> I think the Rdn.compareTo() method doesn't fulfill this contract for some special multi-valued
> 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.

View raw message