On Wed, 2006-05-31 at 21:14 -0400, Alex Karasulu wrote: > 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.
>From the Configuration Admin R4 spec (page 70-432): "The name or key of a property must always be a String object, and is not case sensitive during look up, but must preserve the original case." So is it correct in other words to say - "Normalized (for searches) but preserved at the interface"? > > >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. > >> > >> > >> > > > > > > > > >
