geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: DynamicImport-Package problems
Date Sat, 13 Nov 2010 06:34:32 GMT
2010/11/13 Jarek Gawor <>

> Hi,
> I've been looking into the problem described in GERONIMO-5671. The
> root of the problem is the DynamicImport-Package: * header that we
> automatically add to each bundle during deployment. Here's what going
> on. The nexus webapp is a standalone application and contains all the
> necessary jar files including the log4j jar. At some point during the
> app initialization the javax.beans.Introspector API is used to load
> some log4j class. For optimization purposes if Introspector is asked
> about some class Foo it first checks if it can load FooBeanInfo class
> (if the *BeanInfo class is not found the Introspector uses reflection
> to figure out the necessary information).
> The BeanInfo class for the given log4j class does not exist (in the
> application log4j jar or the Pax logging API bundle). However, because
> of the DynamicImport-Package: * and the BeanInfo check that
> Introspector API does, a dynamic wire (for the org.apache.log4j
> package) is established between the application bundle and the Pax
> logging API bundle. Once that dynamic wire is established all further
> classloading for org.apache.log4j package is delegated to the Pax
> logging API bundle. And that results in the ClassNotFoundException
> since the Pax bundle exposes a subset of the log4j API.
> From OSGi classloading perspective this is working as expected but
> obviously that's not how we want things working when deploying an
> application with its own jars.
> I guess we always knew that DynamicImport-Package: * is a problem and
> we need to do something about it. I think David has some pretty good
> long term ideas for this problem but I'm wondering if there is
> something we could do maybe in M2 time frame.
> One option is to update the different deployers to add a right set of
> package imports to the application bundle. However, this might take a
> bit of trial and error to figure out the right set of imports. This
> should allow us to get rid of DynamicImport-Package: * but we still
> should allow for DynamicImport-Package headers to be added in the
> application plan. That is, don't add DynamicImport-Package: * by
> default but let users add it if needed.

   I guess that it is hard to figure out the right set of the imports, since
in the old classloader structure, the application could load any class from
the parent classloaders, we might make it the same now.
   Since that we still could configure the dependencies in our plan file,
   a. for car package, as mentioned in shawn, in the building time, we might
contain all the export packages in the serialized data.
   b. for jar package, in the deployment time, we might use packageAdmin
service to find all the export packages for it.
   Then, add all those packages in the import packages of the deployed
application. We might also allow configure the private package in the
deployment plan,
   depending on the configuration, we could remove these packages from the
import package lists.
   With this way, we might have a big list for the application bundle, not
sure it would bring any efficiency issue ...

> Another potential option is to ensure the application bundle is
> exporting all packages of the jar files it contains (say with some
> attributes so that nothing would wire to it by default). That
> according to the OSGi classloading rules will prevent the dynamic wire
> to be established to a bundle that exports a package that one of the
> application jars contains. With this option we could still continue to
> have DynamicImport-Package: *.

    I have thought for this idea in the past, but for another scenario, the
library bundle of the ear package.

> Thoughts?
> Jarek


View raw message