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:
- 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.)
- 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.