geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Hardersen <try...@jotta.no>
Subject Re: plugin classloader question
Date Wed, 19 Aug 2009 13:34:41 GMT
I believe the relevant G22 documentation is located here:

http://cwiki.apache.org/GMOxDOC22/classloading.html

On "hidden-classes" it says:

Including a filter in a hidden-classes element prevents matching classes
from being loaded from any parent classloader. This is used when the current
module depends on a different version or when the class represents a
framework that must be initialized independently from the same framework
used by the parent.
This feature is a bit odd. In addition, all child classloaders will not be
able to load the class from any parent.

There's also some good information in geronimo-module.xsd:

A list of classes which will never be loaded from parent ClassLoaders of
this module. For example, if Log4J was listed here, the module would never
see Geronimo's copy of Log4J. If the module provided it's own Log4J JAR it
would use that, otherwise it would not be able to load Log4J at all.

The classes are specified in zero or more child "filter" elements where each
filter element specifies a fully-qualified class name or prefix.
Essentially, any class that starts with one of the prefixes listed here will
be treated as hidden. For example, if you specify two filter elements
containing "java.util" and "java.lang" then you would really screw up your
application. :)

Based on this I added a "hidden-classes" filter on "org.quartz" to my plugin
deployment descriptor so Quartz is never loaded from the parent classloader.
In general this works well, the only problem is that Quartz loads its
version number and probably some other stuff from properties files. The
version number properties file is called "build.properties" and lives on the
root of the Quartz JAR. I'm unable to exclude it using a "hidden-classes"
filter on "build.properties" or "/build.properties". I guess it would be
possible to exclude it with a filter on "build", but that is rather risky as
it might collide with other dependencies.

Thanks for your help!

Trygve

On Wed, Aug 19, 2009 at 2:59 PM, chi runhua <chirunhua@gmail.com> wrote:

> I can think of 2 approaches for your scenario, you may take a try:
>
> 1. use <hidden-classes/> tag in your deployment plan, you may refer to
> deployment plan section in G2.2 doc;
>
> 2. update <geronimo_home>/var/config/artifacts-aliaes.properties, you may
> refer to  substituting one module with another topic in G2.2 doc;
>
> I can't open G22 doc website from home recently.....:-( so you might want
> to find the page by yourself.
>
> Jeff C
>
>
> On Wed, Aug 19, 2009 at 1:02 AM, Trygve Hardersen <trygve@jotta.no> wrote:
>
>> Sometimes asking the questions makes you think....
>>
>> It seems this can be achieved using the "hidden-classes" element in the
>> module definition. I was probably fooled by Quartz logging version "1.5.2"
>> even if the version really was "1.6.5". I looked at the Quartz source and
>> they are loading the version numbers from a file "build.properties":
>>
>> is = QuartzScheduler.class.getResourceAsStream("/build.properties");
>>
>> I tried to add a "hidden-classes" filter on both "build.properties" and
>> "/build.properties", but I don't think it is excluded. I guess the
>> "hidden-classes" functionality treats this as a package name. Any way to
>> escape it?
>>
>> Thanks!
>>
>> Trygve
>>
>>
>> On Tue, Aug 18, 2009 at 6:17 PM, Trygve Hardersen <trygve@jotta.no>wrote:
>>
>>> Hello
>>>
>>> I'm having some problems with classloading and Geronimo plugins.
>>> Hopefully some of you can share your insight into this.
>>>
>>> I want to use the OpenSymphony Quartz scheduler in my application. The
>>> current version is opensymphony/quartz/1.6.5. OpenEJB also uses Quartz,
>>> but an older version quartz/quartz/1.5.2. The Geronimo plugin I want to
>>> use Quartz from also depends on
>>> org.apache.geronimo.configs/openejb/2.2-SNAPSHOT, which comes with Quartz
>>> since it depends on OpenEJB.
>>>
>>> The problem I'm having is making my plugin load Quartz from the
>>> classloader of my plugin, not from the org.apache.geronimo.configs/openejb
>>> classloader. The problem with loading it from that classloader is, besides
>>> getting the old Quartz version, that commons-dbcp/commons-dbcp is not
>>> available in that classloader. commons-dbcp is needed to use Quartz with a
>>> JDBC JobStore (at least with MySQL):
>>>
>>> java.lang.ClassNotFoundException: org.apache.commons.dbcp.BasicDataSource
>>> in classloader org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car
>>>
>>> I've tried to update OpenEJB to use the same Quartz version as I do so
>>> the groupid and artifactid are the same, but I'm still unable to exclude it
>>> from the classloader of my plugin. Does anyone know how this can be
>>> achieved? What I want is to create a Geronimo plugin that depends on
>>> org.apache.geronimo.configs/openejb but loads Quartz from its own
>>> classloader, not that of org.apache.geronimo.configs/openejb.
>>>
>>> Or to put it more generally, how can I prevent classes defined in
>>> dependent plugins from being used in the current plugin?
>>>
>>> Many thanks!
>>>
>>> Trygve Hardersen
>>> Jotta AS
>>>
>>
>>
>>
>

Mime
View raw message