On Mar 17, 2007, at 2:00 AM, Alex Karasulu (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DIRSERVER-834?
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?
yes.
thanks
david jencks
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
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.
