11-14-06 06:11 PM
[ http://issues.apache.org/jira/brows...244
9672 ]
Emmanuel Lecharny commented on DIRSERVER-760:
---------------------------------------------
Don't spend time on de-finalizing too much
We have some problem with the way schema are dynamically loaded. It seems to
work for a standard server, but integration tests are failing because they
assume that schema have already been generated and try to load the classes.
We have to fix that otherwi
se we wont be able to integrate the schema loading system.
FYI, when we think that we have a correct version of the server, we check it
by launching the following command :
mvn -Dintegration test
It launches a bunch of tests which are used to check that the embedable serv
er still works. Here we have a massive failure. Not a big deal, though, but
it need to be fix
> reading .schema files at server start-up
> ----------------------------------------
>
> Key: DIRSERVER-760
> URL: http://issues.apache.org/jira/browse/DIRSERVER-760
> Project: Directory ApacheDS
> Issue Type: New Feature
> Components: core
> Affects Versions: 1.5.1
> Environment: N/A
> Reporter: Norval Hope
> Attachments: schema_branch.patch, schema_branch.patch, schema_load
er.patch
>
>
> I am submitting a patch for a feature I required, and which I've seen a number of
queries about on the DEV list. Currently the only way to get new .schema information
into ApacheDS is to use the Maven2 plugin, requiring a rebuild of the server (not t
o m
ention working around problems like methods being generated which are too long for Java to h
andle).
> Instead this patch adds support for reading of specified .schema files from serve
r.xml at server startup, via a new interface SchemaLoader and a default implementati
on FileSystemSchemaLoader. The latter supports reading all files matching a specifie
d r
egex in a specified directory (in which case users must be careful to ensure
that files appear lexicographically before their dependant files, ala init.
rc in Linux) or reading an ordered list of file names under a specified dire
ctory. An example server.xm
l snippet is as follows:
> <property name="bootstrapSchemas">
> <set>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Aut
ofsSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Cor
baSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Cor
eSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Cos
ineSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Apa
cheSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Col
lectiveSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Ine
torgpersonSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Jav
aSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Krb
5kdcSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Nis
Schema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Sys
temSchema"/>
> <bean class="org.apache.directory.server.core.schema.bootstrap.Apa
chednsSchema"/>
> </set>
> </property>
> <property name="schemaLoaders">
> <list>
> <bean class="org.apache.directory.server.core.schema.FileSyste
mSchemaLoader">
> <constructor-arg><value>./</value></constructor-arg>
> <!--<constructor-arg><value>.*_openldap.schema</value></co
nstructor-arg>-->
> <constructor-arg>
> <list>
> <value>my1_openldap.schema</value>
> <value>my2_openldap.schema</value>
> </list>
> </constructor-arg>
> </bean>
> </list>
> </property>
> noting that the Maven2 style approach is of course still supported where d
esired. A list is used so that multiple SchemaLoader implementations can be
appended if required (which I do).
> I have also included SchemaFromSearchConverter which can read a schema from anothe
r directory via conventional query, which may come in useful for people using Apache
DS as a virtual directory container of sorts. It is not required by the core patch a
nd
can be excluded if no generic use is seen for it.
> A few issues are still outstanding:
> 1. Is the patch seen as worthwhile by the DEV list and/or are there any
issues with my implementation of it?
> 2. At it's core the patch uses the OpenLdapSchemaParser to read the .sc
hema files, which is currently only available in the Maven2 plugin artifact
> <groupId>org.apache.directory.server</groupId>
> <artifactId>apacheds-core-plugin</artifactId>
>
> which is a bit clunky as it means people need to include this jar in their cla
sspath (or in the UberJar). Perhaps this parsing component should be separated from
the rest of the maven plugin to tidy this up (I don't know maven well enough to do t
his
myself).
>
> 3. If the feature and implementation are ok, what further steps should
I take re preparing the patch for inclusion?
> Thanks (by the way I was previously known as Norbert Reilly)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://iss
ues.apache.org/ji...nistrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ Post a follow-up to this message ]
|