Sahoo wrote:
> Ken Cavanaugh wrote:
>> Snjezana Sevo-Zenzerovic wrote:
>>> Well, it turns out that I am seeing things again :-)
>>>
>>> It was glassfish-common package that already contained gmbal.jar,
>>> not glassfish-nucleus. So, yes, glassfish-api should use
>>> gmbal-api-only, if possible.
>>>
>>>
>> I think I'm getting a little confused here. The thing is that
>> gmbal-api-only and gmbal export exactly the same API, but the
>> implementation is
>> different: for gmbal-api-only,
>> ManagedObjectManagerFactory.createStandalone and createFederated both
>> return a NO-OP impl, while
>> gmbal contains the full implementation. Any bundle that depends on
>> org.glassfish.gmbal (the API package) can be correctly
>> wired (in the OSGi sense) to either gmbal or gmbal-api-only. But
>> there are two issues here:
>>
>> 1. If we load both gmbal and gmbal-api-only into the same GFv3
>> instance, we will have two different classes named (for example)
>> org.glassfish.gmbal.ManagedObject. This could lead to severe
>> problems (e.g. an object that got its @ManagedObject annotation
>> from the "wrong" gmbal bundle will not appear to be an MBean, if
>> that object is later registered with the "right" gmbal bundle.)
>> 2. Any code that calls ManagedObjectManagerFactory.createXXX needs
>> to run with either version of the bundle (for example metro does
>> this). I'm a bit concerned that some code that EXPECTS to get
>> gmbal functionality may end up getting the api only version of
>> gmbal, and not get any MBeans.
>>
>> We need to make sure that, in any release of GFv3 (what is the right
>> term here? I mean any collection of OSGi bundles that we release as
>> a profile/release/packaging or whatever of GFv3), exactly one of
>> gmbal or gmbal-api-only is present, NOT BOTH. I have no idea how we
>> want to package this: perhaps something very small like the nucleus
>> should have gmbal-api-only, while the large release (like the full EJB
>> container) should have gmbal.
>>
> I think you can have an optional Require-Bundle dependency from
> gmbal-api to gmbal. This will ensure that even when both the bundles
> are present and a bundle is wired to gmbal-api, the classes eventually
> come from gmbal.
>
The other alternative that comes to my mind is to make gmbal a fragment
and setting bundle-classpath properly in gmbal-api to insert gmbal's
content ahead of its own. See section #3.8.1 of OSGi R4 spec. The
drawback with this approach is that it will always require you to have
both gmbal-api and gmbal in the system, which is not the case in the
former case.
Sahoo
>