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 Fri, 10 Nov 2006 08:06:38 GMT
    [ ] 
Emmanuel Lecharny commented on DIRSERVER-760:

ok. I also applied it yesturday, but I think I did it with the previous one (not jdk 1.5).
I work from home and office, and I think I committed the one from office; My bad. I hope that
everything is fine on the branch :)

Just a little point : I may be picky abot code convention, but this is just to be sure we
follow commons rules, so don't take it personnaly. I'm sure that after a few commits I will
For instance, you commited this code in apacheds/server-main/src/main/java/org/apache/directory/server/
+        if (log4jProps == null)
+            log4jProps = "";

It would be good to add enclosing { and }.

Something we may want tod discuss is the use of the 'final' keyword. I personnally don't use
it a lot for many reasons, but essentially because I find its semantic not clear enough in
Java. Let me explain :
- final for class and method makes sense, and should be use from time to time.
- final for fields are acceptable for constants, associated with static , like in public static
final int ERROR_LEVEL = -1; Otherwise, I don't really think this is usefull (even for guarantee
a unique instanciation in constructor), because the semantic of final is quite different in
this case
- final for inner variables does not make sense except if those variables are used in inner
classes. If you have to declare a variable final, then one can ask the question : shouldn't
it be a constant ? Again, it's more or less a question of semantic
- final for parameters makes sense only if you want to insure invariance. That's a pity that
java does not use the const keyword... This is sometime usefull especially for public API.

This is IMHO, of course. I just find it  a pity that this keyword has so many different semantics,
and I also find it a little bit overuse and tools like PMD are trying to make you think that
you should use it almost everywhere. It hurts my eyes to see final everywhere :)

I don't want to start a religious war. May be we can discuss the use of final in the ML, because
there are quite good arguments in favor of its use (we don't use it a lot inj ADS, and this
may be bad). May be we should also try to use it more, in order to have a little bit more
defensive code...

wdyt ?

> reading .schema files at server start-up
> ----------------------------------------
>                 Key: DIRSERVER-760
>                 URL:
>             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_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