You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2007/01/22 01:58:29 UTC
[jira] Created: (DIRSERVER-834) Schema partition bootstrap code
should be more flexible and reliable
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
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
[jira] Updated: (DIRSERVER-834) Schema partition bootstrap code
should be more flexible and reliable
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ 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.patch
> 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
[jira] Resolved: (DIRSERVER-834) Schema partition bootstrap code
should be more flexible and reliable
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks resolved DIRSERVER-834.
------------------------------------
Resolution: Fixed
Fix Version/s: 1.5.0
I've committed this in rev 519215. Unfortunately svn got confused and I lost history: the files in bootstrap-extract are slight modifications of the files that I removed from bootstrap-partition.
Integration tests all pass for me, but I'm still nervous about this. If this causes problems please let me know and I'll do my best to help straighten them out.
> 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.
[jira] Commented: (DIRSERVER-834) Schema partition bootstrap code
should be more flexible and reliable
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ 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.
Re: [jira] Commented: (DIRSERVER-834) Schema partition bootstrap code should be more flexible and reliable
Posted by David Jencks <da...@yahoo.com>.
On Mar 17, 2007, at 9:21 AM, Alex Karasulu wrote:
> Sounds good to me. I just checked it out superficially and it all
> seemed fine.
>
> Just some questions though on usage.
>
> Those who want to build a non-default pre-populated
> schema partition will now use the partition plugin in some project
> to build their
> partition right?
>
> Then their derivative work would replace their partition containing
> jar to be extracted
> in place of the original jar?
>
> Is this alternative partition jar going to be the same file name as
> the original? Or will
> it have a new name determined by the embedding project? If so then
> is there some
> configuration option that will look for that jar instead of the
> original stock partition jar
> and what would that configuration be if this is the case?
You use the maven dependencies of the project in which you are
setting up the new server that uses the new partition jar. If you
include exactly one partition jar in the classpath (dependencies)
then the extraction code can find exactly one resource named
org/apache/directory/server/schema/bootstrap/partition/DBFILES
and that identifies the jar with the partition stuff in it that needs
to be extracted.
I was originally hoping that you could include lots of jars, one
schema per jar, and they'd all get loaded, but either I don't
understand the format of the partition jar (certainly true :-) or the
data in the files inside is all interlocked across files (which
talking with alex led me to believe) and I concluded that I wouldn't
be able to get that to work. But what is there is still useful -- I
used it in my triplesec branch to set up a server with the triplesec
schemas already in it for testing.
>
> Perhaps we need a simple confluence page that describes this
> feature and how to use
> it?
My documentation skills are pretty much untested and undocumented but
if you make a blank page in an appropriate location I'll try to fill
in some details. (I have no idea where to put it... I'm not really
trying to make you do half the work :-)
thanks
david jencks
>
> Alex
>
> On 3/17/07, David Jencks < david_jencks@yahoo.com> wrote:
>
> 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.
> >
>
>
Re: [jira] Commented: (DIRSERVER-834) Schema partition bootstrap code should be more flexible and reliable
Posted by Alex Karasulu <ak...@apache.org>.
Sounds good to me. I just checked it out superficially and it all seemed
fine.
Just some questions though on usage.
Those who want to build a non-default pre-populated
schema partition will now use the partition plugin in some project to build
their
partition right?
Then their derivative work would replace their partition containing jar to
be extracted
in place of the original jar?
Is this alternative partition jar going to be the same file name as the
original? Or will
it have a new name determined by the embedding project? If so then is there
some
configuration option that will look for that jar instead of the original
stock partition jar
and what would that configuration be if this is the case?
Perhaps we need a simple confluence page that describes this feature and how
to use
it?
Alex
On 3/17/07, David Jencks <da...@yahoo.com> wrote:
>
>
> 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.
> >
>
>
Re: [jira] Commented: (DIRSERVER-834) Schema partition bootstrap code should be more flexible and reliable
Posted by David Jencks <da...@yahoo.com>.
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.
>
[jira] Commented: (DIRSERVER-834) Schema partition bootstrap code
should be more flexible and reliable
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ 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?
> 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.
[jira] Updated: (DIRSERVER-834) Schema partition bootstrap code
should be more flexible and reliable
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (DIRSERVER-834) Schema partition bootstrap code
should be more flexible and reliable
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRSERVER-834.
---------------------------------------
closed
> 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.
[jira] Commented: (DIRSERVER-834) Schema partition bootstrap code
should be more flexible and reliable
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ 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