Object class "objectClass" is called "ObjectClass" in search results

• Key: DIRSERVER-855
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Emmanuel Lecharny
• Reporter: Stefan Zoerner
• Component/s: core
• Affects Version/s: 1.0.1
• Fix Version/s: 1.5.1

Environment

* ApacheDS 1.0.1 (SNAPSHOT, Rev. Rev. 507868)
* Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
* Windows XP Professional SP2

Description

Currently it looks like this:

$ ldapsearch -h localhost -p 389 -D "uid=admin,ou=system" -w ****** -b "dc=example,dc=com" -s base "(objectClass=*)"
version: 1
dn: dc=example,dc=com
dc: example
ObjectClass: domain
ObjectClass: extensibleObject
ObjectClass: top

Although obviously not important: I would expect attribute "objectClass" here (as it is called in the schema). The issue arises with all entries, newly created ones as well.

Comments

[Stefan Zoerner]

Not as important as other things to get a valid 1.0.1, therefore I move it to 1.0.2

[Emmanuel Lecharny]

Yeah, this is a nasty side effect. We have a real problem with uper/lower casing in x. It should be fixed in 1.5.

I don't see any easy solution for 1.0.x

[Emmanuel Lecharny]

The returned entry will use objectClass instead of ObjectClass. For every attributes, the standard case for each attribute as specified in the schema will be used : don't expect to receive OBJECTCLASS if you do a search with (OBJECTCLASS=*).

Will be fixed in 1.0.2 and 1.5.0

[Emmanuel Lecharny]

Another step would be to return the attributes the user is waiting using the names he gave to the server in the attributes list to be returned. For instance, if the user specify that he wants OBJECTCLASS, then he adds OBJECTCLASS to the list of wanted attributes, and we return all the objectClasses using OBJECTCLASS.

[Emmanuel Lecharny]

Partially fixed in 1.0.2 :
http://svn.apache.org/viewvc?view=rev&rev=515053
http://svn.apache.org/viewvc?view=rev&rev=515055
http://svn.apache.org/viewvc?view=rev&rev=515056
http://svn.apache.org/viewvc?view=rev&rev=515057
http://svn.apache.org/viewvc?view=rev&rev=515058

[Alex Karasulu]

Interesting idea regarding using the user supplied attributes list. I wonder if other servers respect this and return the attribute ID as it was asked for. However note that for the most general case where no requested attribute is supplied (all userApplication attributes are returned) we still have the problem. I guess this is a cute feature to have ... sounds appealing at first but I think just making sure for now that attribute Ids are returned as given on add and modify add/replace operations is preserved.

[Emmanuel Lecharny]

well, atm, the requested attributes are returned as they were provided, except for objectClass which is treated differently, because SchemaService has been modified to handle such cases as adding missing objectClasses.

The test you added to check that the casing is respected works well for all the attributeTypes, otherwise.

Does it worth the pain to deal with people trying to insert OBJECTCLASS as an attribuetType, and expecting to get back OBJECTCLASS? I bet no. For other attributeTypes, like organizationalPerson (for instance), keeping the user's casing seems important, and in fact this is what we have currently implemented.

May be someone would dedicate a few hours writing some complete test cases to check that we respect this contract ? Anyone ?

[Stefan Zoerner]

I think, this is not that important. I have retested the current server, and my original issue is fixed (ObjectClass vanished).

By the way, Alex: Sun Java System Directory Server 5.2 uses the attribute names provided in the search in the results, for instance:

$ ldapsearch -b "dc=magritte" -s base "(objectClass=*)"
version: 1
dn: dc=magritte
dc: magritte
objectClass: top
objectClass: domain

$ ldapsearch -b "dc=magritte" -s base "(objectClass=*)" OBJECTCLASS DC
version: 1
dn: dc=magritte
OBJECTCLASS: top
OBJECTCLASS: domain
DC: magritte

Currently, I have not the chance to test other servers, because I am in the office. But as depicted above -- Not that important.

[Alex Karasulu]

Thanks for testing this out. Emmanuel was dead on with using the case of the attribute ID supplied in the search.

Yes I agree that this is not too critical. It just annoys me personally ... makes the server seem somewhat flaky if it's not adhering to these unspoken expectations.

[Emmanuel Lecharny]

Is it still an issue in 1.0.2 ?

[Stefan Zoerner]

No, it has been fixed in 1.0.2. But the problem is still present in 1.5.0

[Emmanuel Lecharny]

Good enough for me :)

It's one less bug for 1.0.2, and one more for 1.5.1

[Stefan Zoerner]

I have just checked this bug with the current 1.5.0 SNAPSHOT (rev 523736), and it is gone. Everything works just fine. Has anybody deliberately fixed it?

[Emmanuel Lecharny]

I fixed it. Did I forgot to mark the issue 'resolved' ?

[Stefan Zoerner]

This is great, Emmanuel. Thanks! Especially, because it will already work in the upcoming 1.5.0 release.
It was not a very important issue, but I definitely did not like the big "O" in the search results.

And yes, currently, the issue is marked as "In Progress".

[Emmanuel Lecharny]

Hmmmm. This issue stayed in the "In Progess" status too long.

[Stefan Zoerner]

This has been fixed for some time and especially it works in the 1.0.2-SNAPSHOT.