directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [ApacheDS] Anyone know why we're loosing case sensitivity for attribute identifiers with modify operations?
Date Thu, 01 Jun 2006 01:14:55 GMT
John E. Conlon wrote:

>While experimenting/upgrading the OSGi ConfigurationAdmin Service in
>trunks/apacheds/osgi I encountered the lowercase attribute identifier
>issue that Alex brought up last month.  
>At first I couldn't understand why the configuration Admin service was
>not recognizing and properly translating what I thought were correctly
>constructed directory entries to configuration admin updates, then I
>noticed the case of the ldap attribute identifiers. 
>When creating an Entry with an JXplorer the prospective Entry's
>attributes are displayed as the schema defines them (in camelCase), but
>after saving the entry and the attribute identifiers all change to
>lowercase. Yet if entries were added via LDIF they all retain the
Yeah there seems to be some really fishy bug lurking around with case
sensitivity and the manner in which entries are added/modified.

>While it may be okay spec wise to change attributes identifiers from
>camel case to all lowercase it sure creates an uncomfortable user
>experience to see some entries in the DIT use camel case and others
>lower case.  
I agree 100% that this issue must be nixed.  The server has to return
back what you put in.  The present situation is unacceptable; I should
have nixed this a while back.

>This issue also creates a hurdle when comes to offering the OSGi case
>sensitive configuration admin service on top of apacheds. (And down the
>line when we add it's companion the OSGi META Typing service).
Hmm you should never depend on the case of attribute type identifiers. 
You must always presume they can come in any form so you must normalize
them for case.

>Are there any further action plans or thoughts for addressing this
This is on the top of my list if someone else does not beat me to it.

>kind regards,
>Norbet Reilly
>Tue, 18 Apr 2006 18:49:40 -0700
>>I've also had a few run-ins with lowercase being forced which, as you
>>state, is not incorrect behaviour but is upsetting an incorrectly
>>case-sensitive legacy application.
>>My work-around (hack) is far from elegant, but I added a boolean
>>"normalize=false" which I pass in to the main program on the command
>>line (was too dangerous to set in the server.xml file due to Spring's
>>lazy instantiation) which I then use to basically turn off the
>>lowercasing in "String StringTools.lowerCase()" and "String
>>StringTools.deepTrim(String str, boolean toLowerCase)". On reflection,
>>perhaps I should use a system property to set the normalize flag.
>>While doing this I noted some places that weren't calling these
>>methods but instead doing the lowercasing directly, so I've included
>>my patch (for reference rather then suggesting you apply it) against
>>trunks/shared .
>>Perhaps these are the methods are also causing your problems... In
>>particular shared/ldap/util/ may be problematic if
>>it is actually being used.
>>As a side note: what are the feeling about future support of a
>>"non-normalized" mode (obviously using a less hacky approach, or at
>>least renaming the methods to StringTools.possiblyNormalize() etc) for
>>use by clients which:
>>    a. Are using ApacheDS only as a host for proxy partitions and wish
>>to avoid an uneccessary performance hit
>>    b. Are dealing with legacy clients which incorrectly expect case sensitivity
>>    c. Are prepared to guarantee consistency in the case of
>>DNs/attribute names to achieve some performance gains?
>Emmanuel Lecharny
>Tue, 18 Apr 2006 00:02:49 -0700
>>Alex Karasulu a écrit :
>>Hi Alex,
>>        I just noticed the server started to lowercase attribute
>>        identifiers after modify operations to attributes. Since LDAP
>>        is case insensitive wrt the attribute identifiers this does
>>        not prevent correct operation however it's troublesome to me.
>>        Was wondering if anyone else noticed this and if they have any
>>        idea with what or when these problems started to occur.
>>I will check that tonite to be sure that decoding does not modify
>>those attributes.

View raw message