directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [ApacheDS] Anyone know why we're loosing case sensitivity for attribute identifiers with modify operations?
Date Thu, 01 Jun 2006 07:13:36 GMT
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


Mime
View raw message