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 >camelcase. > > 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 >issue? > > This is on the top of my list if someone else does not beat me to it. >kind regards, >John > > >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/NamespaceTools.java 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. >> >> >> > > > >
