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
