dev@glassfish.java.net

Re: [v3] exporting all Metro packages for OSGi

From: Fabian Ritzmann <Fabian.Ritzmann_at_Sun.COM>
Date: Mon, 25 Aug 2008 14:14:52 +0300

On 23. Aug 2008, at 02:26, Richard S. Hall wrote:
> Fabian Ritzmann wrote:
>> On 22. Aug 2008, at 02:11, Richard S. Hall wrote:
>>
>>> Bhakti Mehta wrote:
>>>> I assume this is an approach to the extender pattern. http://gnodet.blogspot.com/2008/05/jee-specs-in-osgi.html
>>>> I was anticipating that we would need to do something like this
>>>> for our service lookups but Fabian is mentioning that exporting
>>>> all packages worked for him. FWIW We are having the apis and
>>>> implementation bundled together in one bundle
>>>> I am still having issues with it so will follow up later on that..
>>>
>>> Yes, that is an example of the extender pattern, but you do not
>>> necessarily need activators with the extender pattern, which is
>>> sounds like the proposed above does use. It is not necessary to
>>> export everything if they are on the bundle class path, since you
>>> will be able to access everything on the bundle class path from
>>> the bundle's class loader, so it is best to avoid exporting
>>> everything. However, as Bill points out, in a world where we have
>>> module private classes then this could also be an issue.
>>
>> The problem is that we got NoClassDefinitionErrors all over the
>> place as long as these particular packages were not exported. As
>> soon as I added exports for exactly these packages the errors went
>> away. I am pretty certain there were no issues with the Bundle-
>> Classpath. We don't have it set and the default is just right.
>
> A bundle's class loader is able to load everything from its own
> class path, otherwise it would not be able to function. If you load
> a class from bundle B (e.g., Bundle.loadClass() or by directly
> gettings its class loader), it will be loaded by bundle B's class
> loader. All subsequent class loads instigated by that class will be
> first directed to bundle B's class loader, which should be able to
> load anything on the bundle class path.
>
> Perhaps I do not understand the scenario well enough, but it just
> doesn't sound right. Can you boil down an example that demonstrates
> the situation for me to look at?

I can put up an example on an internal site. I will follow up
privately, there is no point in posting pointers to an internal site
to an external mailing list.

Fabian