Would like an option allowing attribute id case-sensitivity to be preserved

• Key: DIRSERVER-626
• Type: New Feature
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Emmanuel Lecharny
• Reporter: Norval Hope
• Component/s: ldap
• Fix Version/s: 1.5.1

Description

Currently all attribute ids are normalized to lowercase to facilitate schema lookups, both by the NormalizationService and explicitly by methods like "String StringTools.lowerCase()" and "String StringTools.deepTrim(String str, boolean toLowerCase)".

In my case I am using ApacheDS as a host for custom proxy partitions and therefor would prefer to leave the case of attributes unchanged. There also other interested parties such as those doing OSGi integration.

Comments

[Norval Hope]

Relevant email thread from the DEV list:

Re: [ApacheDS] Anyone know why we're loosing case sensitivity for attribute identifiers with modify operations? John E. Conlon <[e-mail]> to Apache

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.

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.

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

Are there any further action plans or thoughts for addressing this
issue?

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.

[Norval Hope]

Here is the patch for the hacky interim approach I used to get around the case-sensitivity issue in the short term (mentioned in the earlier email thread).

Note some c hanges in the patch involve getting all case adjustments to go through a minimal set of common methods, to allow easy configurational control. The actual modification of behaviour in those common methods is the "hacky" part.

I don't know what is the current status of this issue.

My feeling is that it has been fixed a while ago : when you create or modify an attribute using mixed lower and upper cases, the attribute type is stored as is, even if the server manipulates the attributes using only a lower case version of the AT.

Can someone update the status of this issue ?

If this is still a problem, we will try to fix it in 1.5.1

[Emmanuel Lecharny]

This has been fixed when we fixed DIRSERVER-855