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)
2) renaming the actual equals function to equalsInternal to avoid side
effects
3) everywhere in the code where we have a dn.equals( ADMIN_DN ) we will
keep the call to equals
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 ?

Emmanuel

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

Alex Karasulu a écrit :

> Emmanuel Lecharny wrote:
> 
>
> 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.
 
>
<snip/>
Forget about what I have proposed. This is way too complicated. We must
just fix the JIRA entry for 1.0-RC2. Final.
 
>
> 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

[ Post a follow-up to this message ]