I will add to Ken's excellent notes the following on GlassFish V3
'amx' MBeans:
- in my view, JMXA is an implementation detail to be used if it suits
you or not if it doesn't. It's great for generic environments where
you want to generate MBeans easily from existing parts.
- to be an 'amx' MBean won't require any dependencies on V3 or JMXA,
not even interface dependency
This is very different form GFV2.
While JMXA has now incorporated the basic "amx-isms" as interfaces,
those interfaces define the behavior, but not the implementation; the
MBean need only behave (and be named) according to the specification,
and it will work.
I'll be drawing up an RFC style specification for AMX in V3 which will
define:
- ObjectName convention, including type and name properties of the
ObjectName
- required and optional attributes
- required and optional methods
- various "should" things
All of these will be pretty basic, we don't want to make implementing
things hard.
With this in place, any client will be able to navigate the entire
MBean hierarchy in V3, and get basic functionality out of it.
Lloyd
On Nov 10, 2008, at 10:55 AM, Ken Cavanaugh wrote:
> Jeanfrancois Arcand wrote:
>>
>> Salut,
>>
>> Oleksiy Stashok wrote:
>>> Hi Sebastien,
>>>
>>>
>>>> I want to discuss about how we could add JMX into grizzly
>>>> framework. JF give a good sample how to enable JMX into
>>>> Grizzlywebserver but there nothing into the framework itself. I
>>>> need to be able to monitor my gateway build on grizzly. I could
>>>> use spring jmx, mx4j or others frameworks, but I don't want to
>>>> hack the source of grizzly to be able to monitor.
>>> Cool! :)
>>> Ken Cavanaugh is currently working on implementation of JMX
>>> framework (based on annotations), which will be also used by
>>> Glassfish. IMHO it could be good idea, if you can reuse as much as
>>> possible work Ken has done. This way Grizzly JMX, ideally, could
>>> be reused by GF as it is, or with a minimum changes.
>>
>> -0 We should not tie yourself to a single JMX framework and try to
>> craft an API that can be used by any JMX tool/framework. I'm not
>> saying we cannot use Ken's framework (on the contrary), but the way
>> we expose the information needs to be genrics enought so we can add
>> Wrapper based on the JMX framework used. The GrizzlyWebServer has a
>> simple enough API that it can be used with any JMX framework.
>>
> First off, anything we do in JMX automatically works with any JMX
> tool, since in the end
> we are just implementing MBeans, and JMX from the JDK then provides
> all the different
> connectivity options for attaching tools to MBeans.
>
> What I'm doing in JMXA is defining a set of annotations (like JSR
> 255, which will
> only be available in JDK 7) and a simple API that makes it
> really easy to get fine-grained control over the MBean definition
> and make it easy to
> register the resulting MBeans. Basically you apply the following
> annotations (there's
> a few more I won't mention here):
> @ManagedObject (this may change to follow JMX to @MXBean)
> @ManagedAttribute
> @ManagedOperation
> @ManagedData (not present in JMX JSR 255)
> then use the ManagedObjectManagerFactory to create a
> ManagedObjectManager,
> and then take an instance of an annotated class, and call
> ManagedObjectManager.register() (there a several variants on
> register depending on
> how you get the parent object and the name, following JSR 77
> ObjectName conventions).
>
> For Grizzly, what probably makes the most sense is to apply the
> annotations as
> needed in the core or elsewhere, but make registration optional for
> those Grizzly
> users that want to have a minimal core. The JMXA API (if jarred
> separately) is 5284 bytes
> at present (not including the ManagedObjectManagerFactory class, which
> necessarily brings in everything). The full
> implementation is currently 256K, so we don't want to double the
> default size of Grizzly.
> Basically, you could just have a variable mom of type
> ManagedObjectManager passed
> into the core that is null if MBeans are not used in the core. Then
> don't register
> any MBeans if mom==null, but have something outside of the core that
> can create
> a mom using the ManagedObjectManagerFactory (and this would pull in
> all of the
> JMXA packaging).
>
> It must also be emphasized that JMXA is COMPLETELY independent of
> GFv3: that is
> crucial for ALL of the likely users of JMXA. JMXA will be build and
> delivered separately
> from the rest of GFv3 (this is already true: I have the project
> hosted on Kenai
> as a workspace within my CORBA project).
>
> This does bring up one problem: if Grizzly wants to use JMXA this
> way, I need to do a bit
> of re-packaging. Currently JMXA uses the following packages:
> com.sun.jmxa (annotations, ManagedObjectManager, and
> ManagedObjectManagerFactory)
> com.sun.jmxa.generic (some library code)
> com.sun.jmxa.impl (the main implementation)
> (eventually I'll add com.sun.jmxa.typelib)
> What will need to happen is ManagedObjectManagerFactory will need to
> move into a new package to avoid split package problems. I can't
> put it into generic (it doesn't fit there) or
> impl (I don't want to expose the entire implementation in an OSGi
> environment), so I'll
> probably move ManagedObjectManagerFactory into something like
> com.sun.jmxa.factory. Another possibility is to use reflection to
> access
> the implementation class com.sun.jmxa.impl.ManagedObjectManagedImpl.
> This may be a better option, simply because it keeps the entire API
> in a single package.
>
> Ken.