I know it's a lower priority, but this will trigger yet more growth in
the footprint of the ACC.
- Tim
Jennifer Chou wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>