I believe the relevant G22 documentation is located here:
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!
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 COn Wed, Aug 19, 2009 at 1:02 AM, Trygve Hardersen <email@example.com> 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?
TrygveOn Tue, Aug 18, 2009 at 6:17 PM, Trygve Hardersen <firstname.lastname@example.org> wrote:
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?