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.