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
