From dev-return-14039-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Thu Nov 02 03:24:41 2006 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 91979 invoked from network); 2 Nov 2006 03:24:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Nov 2006 03:24:39 -0000 Received: (qmail 96516 invoked by uid 500); 2 Nov 2006 03:24:50 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 96284 invoked by uid 500); 2 Nov 2006 03:24:49 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 96273 invoked by uid 99); 2 Nov 2006 03:24:49 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Nov 2006 19:24:49 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Nov 2006 19:24:37 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id A6E707142BF for ; Wed, 1 Nov 2006 19:24:17 -0800 (PST) Message-ID: <14355047.1162437857681.JavaMail.root@brutus> Date: Wed, 1 Nov 2006 19:24:17 -0800 (PST) From: "Norval Hope (JIRA)" To: dev@directory.apache.org Subject: [jira] Commented: (DIRSERVER-760) reading .schema files at server start-up In-Reply-To: <17758845.1160663915139.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ http://issues.apache.org/jira/browse/DIRSERVER-760?page=comments#action_12446439 ] Norval Hope commented on DIRSERVER-760: --------------------------------------- No problem, always trying to help. Here are the answers to your questions: 1) no classes are generated, I just parse the .schema file and create the same objects that the Maven plugin-generated code would when run. 2) N/A 3) Dependencies are handled by simple ordering (ala Unix init tasks) rather then explicit statement of dependencies. Hence a core schema needs to appear before one that relies on it. Two methods are currently supported: 1) reading list of files explicitly named in server.xml or 2) read alpha-sorted list of files matching a regex in a named directory (in which case file names need to be chosen carefully so dependency ordering is respected). The per-partition schema concept is one of my target use-cases and I included some extra code which can contribute schema information for an external directory server via standard LDAP querying it. The problem I had when running it was that contributing content to the global registries after startup had no effect as the it seems the bootstrap registries were always used. In the past I had a hack which got around this problem but is stopped working three months or so ago and I haven't bothered revisting it. Two points remain that I'm not clear on: a) Whether my proposed patch needs further thought in the "embedded" ADS use-case b) Whether syntax defs and matching rule defs are as dynamic as attribute types and object classes. OpenLdapSchemaParser doesn't have any methods returning them as it does for attr types/object classes so I presume they are simply deduced via "create on reference" or something like that. My current code ignores them (assuming they have all been defined via the Maven generated code), but will be easily updated once I know what to do. Thanks for the PS too. I completely understand, but at the same time was expecting at least a glimmer of interest ;-) > 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: > > > > > > > > > > > > > > > > > > > > ./ > > > > my1_openldap.schema > my2_openldap.schema > > > > > > 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 > org.apache.directory.server > apacheds-core-plugin > > 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