directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-760) reading .schema files at server start-up
Date Thu, 09 Nov 2006 04:18:38 GMT
    [ http://issues.apache.org/jira/browse/DIRSERVER-760?page=comments#action_12448361 ] 
            
Norval Hope commented on DIRSERVER-760:
---------------------------------------

After submitting a tidier patch, here are some answers/comment son Emmanuel's questions/notes:

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

If by this you mean persisting whats read from the .schema files into LDAP representation
in the JDBM backend, then I can see that's possible but don't really see the motivation. The
schema import process at start-up adds very little overhead, so runtime impact is not a big
motivator. My concern with persisting the schemas imported is simply that it makes them harder
to manage, instead of commenting out a line in a server.xml to hide a schema I'd need to delete
a bunch of LDAP objects. While there is a single global schema this is quite problematic as
objects from all the .schemas are mixed together.

My primary use-case if for schema information to be contributed dynamically after start-up,
for instance just prior to activating a custom partition requiring additional schema support.

> 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 :)

I prefer explicit solutions too but see problems with a Spring approach because the most important
part of manually added schema items in the pluggable code that actually implements added behaviour
(other then that there are mainly just basic attributes like names and OIDS). As far as I'm
aware Spring can't help too much with the need for custom code except for allowing you to
create named classes, and creating constructor chains of named classes. That's why I said
in a previous comment that I thought an extra class for every manually added schema item wouldn't
be the best path.

> 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 :)

I'm afraid I don't know Maven very well so I may need to ask for help in the tidy-up, when
we get to this phase. For instance with the conf/*.schema files I'm currently getting the
uber-jar to read, I don't know how i'd get Maven to copy them around and/or where would be
the best place to copy them to, so that installer/embedded/uberjar release flavours can all
find them. So karma isn't necessarily a complete answer.

> 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'm happy to help as time permits, once the details have been reviewed so that there is a
sufficient level of confidence to start documenting.

As an aside, who is the guru of the existing schema code? Is it Alex? Is there any chance
we can get this person to cast their eye quickly over my patch (once it's committed on the
schema branch) and get any feedback on some of my questions in the comment trail for this
issue?



> 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

        

Mime
View raw message