Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <3420579.1187723371291.JavaMail.jira@brutus>
Date: Tue, 21 Aug 2007 12:09:31 -0700 (PDT)
From: "David Jencks (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Commented: (DIRSERVER-834) Schema partition bootstrap code
 should be more flexible and reliable
In-Reply-To: <3447721.1169427509944.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DIRSERVER-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521555 ] 

David Jencks commented on DIRSERVER-834:
----------------------------------------

Working on triplesec I found that the maven dependency between core and the standard bootstrap-partition jar makes it very hard to swap bootstrap partitions.  In rev 568235 I changed this so you get to specify the bootstrap partition you want to use when you are assembling the server.

I don't know how to see if this breaks the installations but the integration tests pass.

> Schema partition bootstrap code should be more flexible and reliable
> --------------------------------------------------------------------
>
>                 Key: DIRSERVER-834
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-834
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>    Affects Versions: 1.5.0
>            Reporter: David Jencks
>            Assignee: David Jencks
>             Fix For: 1.5.0
>
>         Attachments: DIRSERVER-834-2.patch, DIRSERVER-834.patch
>
>
> Currently the extraction code is packed together with the output of the apacheds-bootstrap-plugin into the same jar.  However, the extraction code blythely assumes that there's only one set of files to be loaded available on the classpath.  This makes it needlessly difficult to change the bootstrap schemas (you have to include the extraction code yourself) and dangerous (there's no check that only one set of files exist).
> I'd like to
> - put the extraction classes in a separate jar
> - change them to check that there is only one set of files to try to load.
> After this it should be easy to set up a jar with the bootstrap schemas you need for a particular apacheds application by using the apacheds-bootstrap-plugin and then include that jar in the server cp for that application and get the schemas you need with no setup code.
> Apparently there's been some misconception that getClass().getResource() will only load from the jar the class is in.  Looking at the code involved, Class.getResource delegates to the class's classloader, which proceeds (in general) to start by searching the parent classpath. If not found it calls findResource. The javadoc for URLClassLoader.findResource says:
>      * Finds the resource with the specified name on the URL search path.
> so there is no restriction to the jar the class came from.
> So, I think that even if we keep the extraction classes in the same jar as the files to extract we should make sure there's only one set in the classpath to unpack.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.