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).
A+
-- Jeanfrancois
>
> Ken.
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net For additional
> commands, e-mail: dev-help_at_grizzly.dev.java.net