directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: [ApacheDS] Anyone know why we're loosing case sensitivity for attribute identifiers with modify operations?
Date Wed, 31 May 2006 22:51:32 GMT
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.
> >>        
> >>    
> >>
> >
> >
> >  
> >
> 


Mime
View raw message