geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: DynamicImport-Package problems
Date Thu, 18 Nov 2010 07:35:28 GMT
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 <xhhsld@gmail.com>

>
>
> 2010/11/13 Jarek Gawor <jgawor@gmail.com>
>
> 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

Mime
View raw message