Fetching the schema fails on some LDAP clients

• Key: DIRSERVER-320
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Alex Karasulu
• Reporter: Stefan Zoerner

Description

Fetching the schema fails on some LDAP clients I tried. Some others are able to retrieve a subset of the schema. E.g. Softerra LDAP Adminstrator displays some object classes, some are missing (for instance top, inetOrgPerson). Therefore the creation of entries by some GUI clients may not work (e.g. if the client provides support by displaying required and optional attributes). This is especially true for Softerra.

I am not 100% sure, but I assume the problem lies in in the textual respresentation of schema elements in the schema subentry. Here is an example:

Objectclass "top" looks to client like this for Apache DS:
( 2.5.6.0 NAME 'top' DESC 'top of the superclass chain' STRUCTURAL MUST objectClass MAY )
and like this for another server I checked:
( 2.5.6.0 NAME 'top' DESC 'Standard LDAP objectclass' ABSTRACT MUST objectClass X-ORIGIN 'RFC 2256' )

I guess some tools have problems with the empty "MAY". The same is probably true for empty "MUST" parts. Therfore inetOrgPerson does not appear in Softerra, but person does (person has both MAY and MUST attributes).

The problen does not only occur in some GUI clients, but also in JNDI code, if you use the schema functionality (for many of your users this may be more critical). You find a JNDI example attached to this issue report which crashes an Apache DS but runs without problems on other solutions. Maybe the JNDI parser has the same problem with empty MUSTs and MAYs. Problem is comparable, e.g. fetching "top" causes an exception, "person" does not.

Btw.: Within the JXplorer client there are no problems.

Comments

[Stefan Zoerner]

This little JNDI program displays the required attributes for an objectclass including those inherited by parent classes.
It uses JNDI schema fetching functionality. You may use it to confirm the problem with Apache DS I filed.

For another LDAP server output for "person" looks like this (the program fetches person and top):
person requires sn
person requires cn
top requires objectClass

On Apache DS it creates an Exception (on the client), output looks like this:
person requires sn
person requires cn
javax.naming.NameNotFoundException: top
at com.sun.jndi.toolkit.dir.HierMemDirCtx.doLookup(HierMemDirCtx.java:109)
at com.sun.jndi.toolkit.dir.HierMemDirCtx.getAttributes(HierMemDirCtx.java:464)
at com.sun.jndi.toolkit.dir.HierMemDirCtx.getAttributes(HierMemDirCtx.java:459)
at schematest.RequiredAttributesForAnEntry.main(RequiredAttributesForAnEntry.java:25)

[Stefan Zoerner]

I modified the checks in class org.apache.ldap.common.schema.SchemaUtils which determine whether the MAY and MUST sets of attributes are empty (two lines, see patch-file attached).
 
Now all the GUI clients I have and even th JNDI program I attached some hours ago work properly. Therefore you may consider to apply it to your code.

[Alex Karasulu]

I applied your patch stefan thanks. However there are other issues which I am still tracking down with this issue. Name the fact that the top objectClass is listed as STRUCTURAL when it should be ABSTRACT. For some reason the schema generation plugin is not properly generating the objectClass for TOP. Perhaps this is systemic. Regardless I'll resolve this issue, rebuild the jars, and deploy them once I get to the bottom of these problems.

 

[Alex Karasulu]

Committed changes to fix the objectClass type in revision 239213. Turns out all the ObjectClasses were defaulting to STRUCTURAL. This is now fixed and the proper objectClass type values i.e. STRUCTURAL, ABSTRACT, AUXILIARY should not appear correctly.

[Stefan Zoerner]

I have retested the user experience on the current ApacheDS with the schema browser from Softerra. I also used some JNDI test cases that fetch schema information via API calls. Tada -- everything works like I would expect. It even provides the correct class types, Alex mentioned. And so I am happy and close this issue.