directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Fixing LdapName.equals (was Re: Why is equals() in class LdapName case-sensitive?)
Date Sat, 22 Apr 2006 14:20:41 GMT
Alex Karasulu a écrit :

> 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.   

> <snip/>

well, as stated by Alex, it may not be a good idea. Th epoint, rised by 
Alex, is that LdapName.equals() has missed the target. There is a 
equalsIngnoreCase() method that should have been used instead, and 
equals() should have been case insensitive. I agree with this opinion.

>> 2) renaming the actual equals function to equalsInternal to avoid 
>> side effects
>
<snip/>
Forget about what I have proposed. This is way too complicated. We must 
just fix the JIRA entry for 1.0-RC2. Final.

>> 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.

Agreed. Full of common sense.

> 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.

What we can do then is to delete this LdapName class, and merge it with 
LdapDN, thus avoiding confusion between ADS class and JDK 1.5 class. We 
are writing a LDAP server, not a newer implementation of JNDI :)

Thanks Alex for the head up.

Emmanuel

Mime
View raw message