directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Fixing LdapName.equals (was Re: Why is equals() in class LdapName case-sensitive?)
Date Sat, 22 Apr 2006 13:59:44 GMT
Emmanuel Lecharny wrote:
> Hi everybody,
>
> I just wanted to ask if this could be an acceptable solution to fix 
> LdapName.equaks this way for 1.0-RC2 :
> 1) modification of equals to reflect JDK 1.5 LdaName behavior (i.e. 
> values are compared case insensitive)
Yes we can do this.  It was an arbitrary decision both for JDK authors 
and us to pick case sensitive verses case insensitive comparisons.  This 
is because as this thread pointed out, you don't have schema information 
to correctly make the decision.   Client side comparisons without 
attributeType info will not always work right in either way. 

For example in the JDK LdapName implementation cases sensitive 
attributes in name components will be incorrectly compared.  Let's use 
an example.  Take for example an entry that uses unixFileName as an RDN 
attribute.  It can have two files with same spelling but different 
case.  So these two entries would be different:

unixFileName=file:///usr/local/bin/AFILE,ou=files,ou=system
unixFileName=file:///usr/local/bin/afile,ou=files,ou=system

According to the LDAP schema unixFileName is case sensitive.  But here 
LdapName from the JDK will not consider these entries as different.  The 
ApacheDS version of LdapName will consider them different. 

Switch the example to use a windowsFileName now.  Here both DNs refer to 
the same file and to the same entry:

windowsFileName=file://C:/AFILE,ou=files,ou=system
windowsFileName=file://C:/afile,ou=files,ou=system

In this example the ApacheDS LdapName implementation would be incorrect 
thinking both entries are different.  The JDK implementation would 
correctly compare the to entries.  So both implementations will have 
issues under different circumstances depending on the name component 
attributes used in the DN.

> 2) renaming the actual equals function to equalsInternal to avoid side 
> effects
Hmm yeah I see what you mean.  The problem for us is that ApacheDS 
internally uses this equals method for comparisons after normalization 
of a DN.  See our version of LdapName is special because it presumes 
normalization has weeded out DN variance in advance.  So what is left to 
be compared has been case normalized and a comparison with case 
sensitivity enabled makes a lot of sense.

I don't know if making our LdapName behave the same as the JDK LdapName 
is a good move for us since ignoring case by default now may break 
things.  In fact it will break many things and add confusion for us.  I 
think it's best that we tell people we care about case unlike the JDK 
and leave it at that.
>
> 3) everywhere in the code where we have a dn.equals( ADMIN_DN ) we 
> will keep the call to equals
Makes no difference.  Really we'll still have breakage.  Things like uid 
attributes will begin to fail when trying to differentiate uids with 
different case.
> 4) LdapDN will also be modified in the same way
>
> I think this will work, and won'ty impact the code base too much.
>
> For 1.1, I will favor another solution :
> 1) LdapName will be replaced by LdapDN (I mean, LdapDN will be renamed 
> LdapName) (DIRSERVER-171)
> 2) Compatibility with JDK 1.5 LdapName class will be fulfilled 
> (DIRSERVER-182)
> 3) We will also have to fix issue DIR-184 (leading and trailing 
> escaped spaces)
>
> wdyt ?
Hmmm man I would stay away from trying to fall in line with the JDK 
LdapName.  There are some things we should correct but I think this case 
sensitivity issue is something best left as a *WARNING* in caps to 
users.  It should state this is how we differ from the JDK version of 
LdapName.  If you write client side JNDI code feel free to use the JDK 
version of LdapName.  If you write server side ApacheDS code well use 
the ApacheDS LdapName.

Changing this I don't think gives us a benefit minus the occational user 
that may complain about our LdapName not being the same.  I'm ok with 
that because our entire premise to correct server side operation is 
based on the normalize then compare approach.  LdapName comparisons on 
the server work right if they consider case.

Alex

P.S. Sorry if this was not that clear .. have not had my morning coffee yet.



Mime
View raw message