Jeanfrancois Arcand wrote:
> Salut,
>
> 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.
>
> Great.
>
>>
>> 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.
>
> +1
>
> 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:
>
> Great :-)
>
>
>> 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.
>
> OK let's discuss the details/time frame during our weekly meeting this
> Wednesday. The big question is would it make sense to add support for
> 1.9.0 (we can delay the release a couple of days).
>
OK, that's a good time. What is the 1.9.0 schedule? I have quite a bit
of work to do
to get ready for 1.9.0 (finish current API and deal with packaging at
least).
Also, I think we may be able to set things up so that MBean support is
turned on
simply by including the jmxa-impl.jar in the classpath (and probably
some OSGi
magic at some point as well if running in that environment). Basically,
I can
just make ManagedObjectManagerFactory.create return null if it can't find
the ManagedObjectManagerImpl class (because jmxa-impl.jar is not available),
and then we write the code so that no attempt is made to register MBeans
unless
the ManagedObjectManager is not null. This is probably a really easy
way to make
this optionally available to the end user with no API requirements.
Ken.