geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <jga...@gmail.com>
Subject DynamicImport-Package problems
Date Sat, 13 Nov 2010 05:12:57 GMT
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.
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: *.

Thoughts?

Jarek

Mime
View raw message