Hi!
I've been using ApacheDS wrapped into a small ServletContextListener which
instantiates the directory server within a servlet and automatically creates
some default directory entries when it runs for the first time.
This worked fine in 1.5.5, except for some known problems with that version (an
awful lot of log warning at runtime and exceptions when trying to query
groupOfUniqueNames). So I recently upgraded to 1.5.6 and now to 1.5.7. The
1.5.6 upgrade required extensive changes to my initialization code, but after
that my test cases completed without problems.
Only the servlet doesn't work in Tomcat anymore. I keep getting this error when
initialising ApacheDS:
15:09:39 [ERROR]
org.apache.directory.shared.ldap.schema.loader.ldif.LdifSchemaLoader:112 -
ERR_10004 Expecting to find a schema.ldif file in provided baseDirectory path
'D:\tools\Tomcat 6.0.26\temp\server-work-default\schema\ou=schema.ldif' but no
such file found.
I've traced the problem to ResourceMap#getResources():
String classPath = System.getProperty( "java.class.path", "." );
String[] classPathElements = classPath.split( File.pathSeparator );
Apparently, ApacheDS searches through its own class path to find all LDIF files
matching a certain pattern and instantiates them; if this doesn't succeed, it
won't initialise. But in Tomcat, "java.class.path" contains only one single
entry, and that's the bootstrap.jar. I don't know much about Tomcat (or servlet
containers in general), but it doesn't seem that there's any guarantee that
querying "java.class.path" this way is actually going to work - certainly not
when more obscure class loaders are used which don't actually use a class path.
Is there a different way to initialise an ApacheDS instance that works with
less specific assumptions about the class path and class loader? Or is this
actually a bug - and if so, what's the prognosis on a fix?
Cheers,
Marian.