Snjezana Sevo-Zenzerovic wrote:
> 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...
I will go ahead and make this change - for now glassfish-api will depend
on full gmbal.
Snjezana - when you're ready you can change glassfish-api to depend on
gmbal-api-only.
Thanks,
Jennifer
>
> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>