directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] Commented: (DIRSERVER-760) reading .schema files at server start-up
Date Thu, 02 Nov 2006 08:28:17 GMT
    [ ] 
Emmanuel Lecharny commented on DIRSERVER-760:

Regarding dependencies : there is no way to handle them simply but building a kind of association
between Objects/attributes (O/A) and the file where we found them. At the end, either we have
created a full tree, or there are lacking elements, and we must discard one or more file,
generating an error log.

Regarding your patch :
1) We need to read it thoroughly, and this is my intention for the next couple of days. 
2) It would be very cool if patches contains javadoc, comments and use the ADS coding convention
(which, obviously, is pretty much an oral tradition than a written rule, so I guess nobody
by current committers now about :) It helps a lot to understand the design and intention (I
must admit that I don't really know this part of the server)
3) As this is really a very important part of the server, deep tests should be run, and I
think it may deserve to be applied in a branch, until we pass successfully all the tests,
including VSLDAP tests (the one about Open Group certification)

The matching rules might be a little bit more static, because I don't know anybody who added
one in any server. This is pretty much something that is hardwired in the server atm. But
we can really include tham as plugins, via spring configuration (or osgi in the near future).
Thought in progress...

PS2 : yeah, I understand that you felt a little bit disapointed... However, you also have
to understand that we are volunteer, and after having spent one week in Austin, working, discussing,
(drinking), we were a little bit burnt out when coming back home. I personnally had to deal
with a damn jet lag and more than 2000 mails, plus many importants other things to do (ya
know, familly, friends, job etc). Nothing get lost when using JIRA, it's pretty much a question
of time and energy to read them and respond to them :)

> reading .schema files at server start-up
> ----------------------------------------
>                 Key: DIRSERVER-760
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 1.1.1
>         Environment: N/A
>            Reporter: Norval Hope
>         Attachments: schema_loader.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 to mention working around
problems like methods being generated which are too long for Java to handle).
> Instead this patch adds support for reading of  specified .schema files from server.xml
at server startup, via a new interface SchemaLoader and a default implementation FileSystemSchemaLoader.
The latter supports reading all files matching a specified regex 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 directory. An example server.xml snippet is as follows:
>     <property name="bootstrapSchemas">
>       <set>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>         <bean class=""/>
>       </set>
>     </property>
>     <property name="schemaLoaders">
>         <list>
>             <bean class="">
>                 <constructor-arg><value>./</value></constructor-arg>
>                 <!--<constructor-arg><value>.*_openldap.schema</value></constructor-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 desired. A list
is used so that multiple SchemaLoader implementations can be appended if required (which I
> I have also included SchemaFromSearchConverter which can read a schema from another directory
via conventional query, which may come in useful for people using ApacheDS as a virtual directory
container of sorts. It is not required by the core patch and 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 .schema files,
which is currently only available in the Maven2 plugin artifact     
> <groupId></groupId>
> <artifactId>apacheds-core-plugin</artifactId>
>     which is a bit clunky as it means people need to include this jar in their classpath
(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 this 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:
For more information on JIRA, see:


View raw message