[
https://issues.apache.org/jira/browse/DIRSERVER-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466404
]
David Jencks commented on DIRSERVER-834:
----------------------------------------
I've attached a patch that appears to do what I intend and includes a simple
test for the duplicate detection. All the integration tests pass for me.
I'm not sure how to verify that an installed server will start correctly. Is
there an example I can test?
> 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.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.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
