[
https://issues.apache.org/jira/browse/DIRSERVER-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks updated DIRSERVER-834:
-----------------------------------
Attachment: DIRSERVER-834-2.patch
This patch fixes a bunch of issues when you try to actually use a different
bootstrap partition jar. I have use of an alternate bootstrap partition jar
working in the sandbox/triplesec-jacc2 branch.
I still don't know how to test if a normal apacheds server will start with
these changes or if a classpath adjustment is needed.
> 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
> Assigned To: David Jencks
> 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.
