directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [jira] Commented: (DIRSERVER-760) reading .schema files at server start-up
Date Mon, 06 Nov 2006 12:50:50 GMT
Norval,

if you produce a Patch, will it ba against apacheds-schema branch? I have
included your path specifically in this branch, so it will be easy to test
your modifications if you do so.

Thanks !

On 11/6/06, Norval Hope (JIRA) <jira@apache.org> wrote:
>
>     [
> http://issues.apache.org/jira/browse/DIRSERVER-760?page=comments#action_12447429]
>
> Norval Hope commented on DIRSERVER-760:
> ---------------------------------------
>
> Have got a solution working (nothing checked in yet) using the approach I
> outlined above, with an optional ???SchemaAdditions class which can
> contribute manual content, and have the server starting up happily.
>
> Still need to consider whether things can be done more explicitly (ideally
> a separate Spring .xml matching .schema files requiring manual content to be
> registered) and what parts of the existing code can be retired/tidied up.
> Will post update shortly.
>
> > 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
>
>
>


-- 
Cordialement,
Emmanuel L├ęcharny

Mime
View raw message