LDAPConnection Cannot Get Schema From InMemoryDirectoryServer

[Jason "JRSofty" Reed]

I've created a mockup of my production LDAP Directory Server using the InMemoryDirectoryServer. I'm creating a schema that I exported from the production Directory Server into an LDIF and passing that in the InMemoryDirectoryServerConfig object. Then during the JUnit tests my code will attempt to perform the getSchema() method on the LDAPConnection object but it is returning null. If I attempt to get the schema through the RootDSE it also returns null.

I also attempted to use a third-party LDAP browser, to read the Schema in formation from the InMemoryDirectoryServer and that fails as well.

Here is an example of my code for creating the InMemoryDirectoryServer instance:

 public static void init()
 {
     InMemoryDirectoryServerConfig config = new InMemoryDirectoryServerConfig("c=de");
     config.addAdditionalBindCredentials("cn=Admin,cn=Users,c=de","<PASSWORD>");
     config.setListenerConfigs(InMemoryListenerConfig.createLDAPConfig("LDAP",null,29389,null));
     config.setEnforceSingleStructuralObjectcClass(false);
     config.setSchema(getSchema());

     InMemoryDirectoryServer server = new InMemoryDirectoryServer(config);
     server.importFromLDIF(true,"file/to/import.ldif");
     server.startListening();

 }

 private static Schema getSchema()
 {
     ArrayList<File> schemaFiles = new ArrayList<File>();
     File directory = new File("./path/to/schema.ldif");
     File[] filesFromDirectory = directory.listFiles();
     for(File file : filesFromDirectory)
     {
         if(!file.isDirectory())
         {
             schemaFiles.add(file);
         }
     }
     return Schema.getSchema(schemaFiles);
 }

So the schema is getting loaded into the InMemoryDirectoryServer because without it the initial directory structure would not load. Only when trying to get the schema back out via the LDAPConnection object failse. Do you have any idea why this is?

[Edit]
I performed some checks with the getting of the Schema like in the previous post, and that didn't work. If I attempt to get the Schema via the server instance itself and that seems to work.
[/Edit]

[Neil Wilson]

I'm not able to reproduce this problem.

I took the code you provided, and made a couple of minor edits to supply my own schema and data LDIF files. I was able to establish a connection to the in-memory server, and calling getSchema() on that connection returned a non-null object with all of the schema elements that were contained in the schema files I provided.

When you're calling getSchema, are you providing an argument to specify the DN of the entry for which to retrieve the schema? If you specified a DN, are you sure that entry exists in the LDIF file you're importing? Can you retrieve that entry from the server using the connection that you've established, and is the subschemaSubentry attribute included in the entry if you explicitly request it? Can you retrieve the entry named in the subschemaSubentry attribute?

[Neil Wilson]

If you can't figure out the problem, then it would be helpful if you could provide a complete standalone program that demonstrates the problem, along with the schema and data LDIF files you're using. If you don't want to attach them here, then you can send them to ldapsdk-support@unboundid.com.

[Jason "JRSofty" Reed]

Hi Neil,

Please find attached an Eclipse project containing the code to recreate the failure, as well as a readme explaining what output I receive when I run this code, and the environment in which I am working.

[Neil Wilson]

Using the information you provided, I was able to reproduce the issue.

The problem is that the LDIF file that contains the schema doesn't have the objectClass attribute. It has the objectClasses attribute, which defines the set of object classes in the schema, but it doesn't have the objectClass attribute (which should have values of at least "top", "ldapSubentry", and "subschema"). When the LDAP SDK is trying to retrieve the schema, the in-memory directory server is evaluating a filter of either "(objectClass=*)" or "(objectClass=subschema)" (depending on which version of the LDAP SDK you're using), but neither of those matches the schema entry because it doesn't include the objectClass attribute.

I have just committed an update to the LDAP SDK that will add the objectClass attribute to the schema entry read from LDIF if it isn't there, which should prevent this problem from happening in the future. However, you can also work around it by simply adding the following three lines to the bw-schema.ldif file:

objectClass: top
objectClass: ldapSubentry
objectClass: subschema

Once I added those lines, your code was able to work and retrieve the schema entry. And the original schema file works with the updated version of the LDAP SDK.

[Jason "JRSofty" Reed]

Ah thanks. Just for your information, I built that LDIF using the UnboundID LDAP SDK. I made a connection to the production server and got the schema with the .getSchema() method and then wrote the entry with an LDIF reader. I'm not sure if that is the reason.

[Neil Wilson]

I have updated the LDAP SDK so that it will request all user attributes in addition to the schema-specific operational attributes when retrieving schema over LDAP.