[ 
http://issues.apache.org/jira/browse/DIRSERVER-760?page=comments#action_12448076
 ] 
            
Emmanuel Lecharny commented on DIRSERVER-760:
---------------------------------------------

To bring some thiughts to you questions :
1) I agree with you. Schema should be available somwhere alese than in jars. 
What we can also do is to preload them into a partition. I'm dreaming of a Ldap 
server which use itself to manage schema... Of course, you will still have 
schema files, but you will just parse them at start only if they have been 
'touched'. Does it sounds crazy ?

1.a) I think that the spring approach seems better, from my point of view. This 
can be discussed. For normalizer and comparator, we should consider that we 
will have System Normalizer/Comparator, and User Defined N/C. Only those last 
classes should be put in Spring file, otherwise, we will end with a monster 
configuration file :)

2) Yes, a lot of dead code will be removed. We can do that in the branch. Man, 
I hope you will get karam quickly :)

3) We badly need some documentation :( I'm trying to improve it, but it takes a 
*lot* of time, as I don't have a deep knowledge of all the code, and to be sure 
that I don't write down stupid tgings. And because english is not my favorite 
language, too :)

I will apply your patch in 2 hours.

> 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_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

        

Reply via email to