directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [jira] Commented: (DIRSERVER-834) Schema partition bootstrap code should be more flexible and reliable
Date Sat, 17 Mar 2007 13:06:16 GMT

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.

View raw message