Cool~! Glad it can help. Jeff C
On Wed, Aug 19, 2009 at 9:34 PM, Trygve Hardersen <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]>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 <[email protected]>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 >>>> >>> >>> >>> >> >
