[jira] Commented: (DIRSERVER-760) reading .schema files at server start-up

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

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

Thanks for the patch !

Having "dynamic" schema is something we want to include in the server, the latest discussion showed that the current solution via a maven plugin is only a temporary solution.

I haven't read your code thouroughly, but I already have a few questions :
1) are you generating .class files from the schema (like the one we are generating with the maven plugin)
2) If so, which tool do you use to compile the files ? (assuming that we can't distribute tools.jar, this can be an issue)
3) what about dependencies? Are they deducted from the references to objects/attributes and from the file where they are declared ?

I do think that the time needed to parse the schema is totally irrelevant, as we don't launch the server every 10 seconds, so even if parsing cost 1 minutes, this is always better than any other static solution.

Last point, I think that generating classes is definitively not the best solution. Here, we want to have a totally dynamic system, and schema just rely on few static classes : matchingRules classes. It should be possible to replace hardwired Objects/Attributes with data structures associated with Abstract class implementing the needed features. We have to think about it, because this will help us to implement future extensions, like per partition schemas, or stuff like that.

I think the subject is wide open, and we can discuss all the pros and cons in this JIRA.

Thanks again, Norval/Norbet :)

PS: your post wasn't forgotten, we just haven't had time/energy to address it lately, due to ApacheCon US.



> 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.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="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