Sounds good to me.  I just checked it out superficially and it all seemed fine.

Just some questions though on usage.

Those who want to build a non-default pre-populated
schema partition will now use the partition plugin in some project to build their
partition right?

Then their derivative work would replace their partition containing jar to be extracted
in place of the original jar?

Is this alternative partition jar going to be the same file name as the original? Or will
it have a new name determined by the embedding project?  If so then is there some
configuration option that will look for that jar instead of the original stock partition jar
and what would that configuration be if this is the case?

Perhaps we need a simple confluence page that describes this feature and how to use


On 3/17/07, David Jencks <> wrote:

On Mar 17, 2007, at 2:00 AM, Alex Karasulu (JIRA) wrote:

>     [
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#action_12481826 ]
> Alex Karasulu commented on DIRSERVER-834:
> -----------------------------------------
> So looking at the commit it seems you separated out the extraction
> code into the
> new partition-extractor module and use the proper class loader code
> to locate a
> single partition jar to extract?


david jencks

>> Schema partition bootstrap code should be more flexible and reliable
>> --------------------------------------------------------------------
>>                 Key: DIRSERVER-834
>>                 URL:
>>             Project: Directory ApacheDS
>>          Issue Type: Improvement
>>    Affects Versions: 1.5.0
>>            Reporter: David Jencks
>>         Assigned To: 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.