Re: [ApacheDS] Anyone know why we're loosing case sensitivity for attribute identifiers with modify operations?

["John E. Conlon" <jc...@verticon.com>]

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.
> >>        
> >>    
> >>
> >
> >
> >  
> >
> 

Re: [ApacheDS] Anyone know why we're loosing case sensitivity for attribute identifiers with modify operations?

[Alex Karasulu <ao...@bellsouth.net>]

John E. Conlon wrote:

>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"?
>
I don't understand what you mean exactly.  Let me clarify what I meant
perhaps this will help.

Do not presume any LDAP server (ADS or other) will return the id in any
specific case.   When you search for entries based on the value of an
attribute the case of the attribute's Id does not matter since the
server will case normalize for you.

Ideally a server should return the attr id as it was provided by the
user when the attribute was added via an add or modify operation.

HTH,
Alex

Re: [ApacheDS] Anyone know why we're loosing case sensitivity for attribute identifiers with modify operations?

[Norbet Reilly <nr...@gmail.com>]

FYI guys,

I opened http://issues.apache.org/jira/browse/DIRSERVER-626?page=all
around case-sensitivity issues, and my particular interest and spin on
the situation.