Salut,
Ken Cavanaugh wrote:
> 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?
November 17 :-) But like I said, we can delay that release as it is more
and more clear that Grizzly 2.0 will not be added to v3. So delaying for
one of two weeks is fine. We also have issues to deal with:
http://tinyurl.com/5mstcu
How long do you need? Can Sebastien/us can help?
A+
-- Jeanfrancois
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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>