directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Jacobson <owen.jacob...@grimoire.ca>
Subject Re: apacheds-maven-plugin and ApacheDS 1.5.7
Date Tue, 28 Sep 2010 19:24:32 GMT
On Tue, Sep 28, 2010 at 2:44 PM, Felix Knecht <felixk@apache.org> wrote:
> On 09/28/10 19:36, Kiran Ayyagari wrote:
>> On Tue, Sep 28, 2010 at 10:49 PM, Owen Jacobson
>> <owen.jacobson@grimoire.ca> wrote:
>>> On Tue, Sep 28, 2010 at 1:11 PM, Kiran Ayyagari <kayyagari@apache.org>
wrote:
>>>> hi Owen,
>>>>
>>>> On Tue, Sep 28, 2010 at 10:10 PM, Owen Jacobson
>>>> <owen.jacobson@grimoire.ca> wrote:
>>>>> Hi there,
>>>>>
>>>>> As you may have seen in another thread this morning, someone's asked
>>>>> that I upgrade apacheds-maven-plugin to ApacheDS 1.5.7. This hasn't
>>>>> gone as smoothly as I had hoped.
>>>>>
>>>>> ApacheDS 1.5.7's mechanism for populating the schema directory
>>>>> involves trawling through every entry in the java.class.path system
>>>>> property looking for JARs that contain schema files. The relevant code
>>>>> is in org.apache.directory.shared:shared-ldap-schema:0.9.19 . Maven
>>>>> doesn't use -classpath (or set java.class.path) when running plugins,
>>>>> so this mechanism fails - the only JAR it finds is Maven's classworlds
>>>>> bootstrap JAR, which obviously has nothing interesting in it. In fact,
>>>>> this mechanism fails for any program that doesn't use the root
>>>>> classloader to load ApacheDS.
>>>>>
>>>>> I think the only universally workable solution is to change the
>>>>> packaging for the schema LDIF files so that instead of being scanned,
>>>>> each JAR that contains schema files also contains an index file at a
>>>>> known location (such as META-INF/apacheds/schema) listing all of the
>>>>> schema files in that JAR. Unfortunately, that's a pretty
>>>>> labour-intensive solution (it means anyone who adds a schema to
>>>>> shared-ldap-schema or related artifacts has to remember to update the
>>>>> index as well, or that someone has to tune the build to generate the
>>>>> index file. I'm happy to set this up, if it turns out to be the best
>>>>> solution. (As you can tell, I'm already fairly adept at extending
>>>>> Maven. :)
>>>>
>>>> hmm, though it helps in reduced scan time this again suffers from the
>>>> same class loading issue
>>>
>>> Not at all. shared-ldap-schema-*.jar is available in the classloader
>>> ApacheDS is being launched with. By asking that classloader for a
>>> resource with a known name (using
>>> ClassLoader.getResources(schemaIndexPath)), we skip the scan entirely
>>> and go straight to reading the files (also using
>>> ClassLoader.getResource... methods). I can patch this up, if you want
>>> a demonstration. :)
>> hmm, I mean will it solve the issue the maven plugin has in finding
>> the schema resources?
>
> Can't we add any jars in question (containing the ldif files) as a
> plugin dependency in the plugins configuration section? So we would have
> the sources. We could even pre-extract the ldif files from the dependent
> jars into a <plugin><configuration><ldifDirectory>...</> directory
and
> then use them from this location.

I'm not willing to impose the use of dependency:unpack on users of
apacheds-maven-plugin, which is what you'd have to use. Adding them to
the plugin's dependency list is insufficient (they're already there,
in fact - they're a transitive dependency of apacheds-all :), since
ResourceMap looks specifically at the java.class.path system property,
not at the classloader ApacheDS's classes are actually being loaded
from.

There's no guarantee that that classloader is enumerable, either, unfortunately.

-o

Mime
View raw message