[
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.
