[
http://issues.apache.org/jira/browse/DIRSERVER-760?page=comments#action_12448675
]
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 stop...
For instance, you commited this code in
apacheds/server-main/src/main/java/org/apache/directory/server/UberjarMain.java
:
+ if (log4jProps == null)
+ log4jProps = "log4j.properties";
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: 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_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="org.apache.directory.server.core.schema.bootstrap.AutofsSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.CorbaSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.CoreSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.CosineSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.ApacheSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.CollectiveSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.InetorgpersonSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.JavaSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.Krb5kdcSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.NisSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.SystemSchema"/>
> <bean
> class="org.apache.directory.server.core.schema.bootstrap.ApachednsSchema"/>
> </set>
> </property>
> <property name="schemaLoaders">
> <list>
> <bean
> class="org.apache.directory.server.core.schema.FileSystemSchemaLoader">
> <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 do).
> 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>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 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
