Ken,
thanks for clarification - if this is the case, and we absolutely
want/need to exclude full gmbal out of nucleus distribution, I think
we'll need to separate both gmbal-api-only and full gmbal into their own
dedicated IPS packages whose dependencies are defined as mutually
exclusive.
If we are going this route, glassfish-api will need to temporarily
depend on full gmbal until I add appropriate packager modules...
Snjezana
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.
>
> Thanks,
>
> Ken.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net For
> additional commands, e-mail: dev-help_at_glassfish.dev.java.net