I attached a draft patch to GERONIMO-5680, it somewhat solves the dynamic import issue. Will be appreciated that some one could help to give some comments. Thanks.
2010/11/13 Ivan <[email protected]> > > > 2010/11/13 Jarek Gawor <[email protected]> > > 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 >> > > > > -- > Ivan > -- Ivan
