You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jim Alateras <ji...@bigpond.net.au> on 2003/09/26 03:20:39 UTC
[merlin] jmx support
Is there anything in Merlin today that parallels JMX support in Phoenix,
in particular the use of .mxinfo files to declare a component's JMX
interface
cheers
</jima>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] jmx support
Posted by Stephen McConnell <mc...@apache.org>.
Jim Alateras wrote:
>Steve,
>
>Thanks for the timely response. I will look into the two options
>described below early next week. My understanding is that this will
>enable me to declare JMX access points to my components. Can you clarify
>whether I need to write the code that will register these points with
>the MBeanServer or does this code exist already....i suspect the former
>
Today - relative to the 3.0 beta release - *no* component MBeans are
registered. The only option available to you is to use some undocumented
features that result in the deployment of an mbean server and the
registration of the Merlin Kernel.
For the final release there are three subjects that are top-of-the-agenda:
1. logging - The logging subsytem in Merlin 3.0 does not use the
excalibur logging package - instead it has a variant based on LogKit.
This is a top priority item as the James project needs a complete
logging solution before they can consider Merlin as a deployment candidate.
2. ECM migration - The 3.0 version of Merlin does not include pooled
object support. This was disabled simply because the notion of a pool
needs to properly expressed at the level of a component type manager -
and the prev. 2.1 version just did not cut it in terms of providing a
good solution.
3. JMX support as described in the prev. email - which breaks down into
pending work on exposure of internal system and tartget component type
management access point handling:
(a) internal auto jmxification of the managing appliance
(b) supplementary registration/deregistration of jmx mbeans
(via qdox or a avalon variant)
I.e. today - it does not matter if you write the code or not because
Merlin 3.0 beta will *not* register the mbean. On a final release you
will probably find that the majority of you management requirements are
taken care of automatically, independently of your deployment context
(web, standalone, or embedded) and any custom content will be handled
based on a supplementary descriptors associated with a component class.
Cheers, Steve.
>
>cheers
></jima>
>
>
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Sent: Friday, 26 September 2003 12:43 PM
>>To: Avalon Developers List
>>Subject: Re: [merlin] jmx support
>>
>>
>>
>>
>>Jim Alateras wrote:
>>
>>
>>
>>>Is there anything in Merlin today that parallels JMX support in
>>>Phoenix, in particular the use of .mxinfo files to declare a
>>>component's JMX interface
>>>
>>>
>>>
>>No.
>>
>>JMX support in Merlin is ... "preliminary". You can startup
>>merlin as a
>>jmx server and via a jmx client invoke shutdown and
>>redeployment. This
>>works just fine. The jmx related strategy covers three areas
>>- (a) how
>>to automate internal jmx handling of appliances (managers of
>>component
>>types) so that componet types become auto-managed relative to Avalon
>>lifecycle interfaces, and (b) how to handle support for custom
>>management interfaces, and (c) how to federate multiple
>>merlin kernels
>>via adapters to a single jmx server management point.
>>
>>In the first area there are some preliminary resources in
>>place but it
>>is largely testing phase at this time. The second area -
>>which is the
>>subject your concerned about can be addressed two ways:
>>
>>(a) use the existing phoenix source code and build into merlin the
>>equivalent functionality
>>(b) use the qdox jmx solution with @jmx tags
>>
>>Either direction presents a few problems. Using the qdox solution we
>>run into problems with their maven plugin which appears to be doing a
>>really strage bunch of things that at the end of the day are not
>>required - but their ant task works fine. Taking this approach would
>>require that we write a maven plugin for the qdox jmx tag
>>handler. But
>>it would be better if the guys from Qdox did this! Going the phoenix
>>style means replicating content that will probably (?) come
>>from qdox.
>>
>>At the end of the day we need a jmx plugin for maven and from the
>>artifacts generated, we need merlin to register and
>>dererigister those
>>management access points as required.
>>
>>Cheers, Steve.
>>
>>--
>>
>>Stephen J. McConnell
>>mailto:mcconnell@apache.org
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>>For additional commands, e-mail: dev-help@avalon.apache.org
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [merlin] jmx support
Posted by Jim Alateras <ji...@comware.com.au>.
Steve,
Thanks for the timely response. I will look into the two options
described below early next week. My understanding is that this will
enable me to declare JMX access points to my components. Can you clarify
whether I need to write the code that will register these points with
the MBeanServer or does this code exist already....i suspect the former
cheers
</jima>
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Friday, 26 September 2003 12:43 PM
> To: Avalon Developers List
> Subject: Re: [merlin] jmx support
>
>
>
>
> Jim Alateras wrote:
>
> >Is there anything in Merlin today that parallels JMX support in
> >Phoenix, in particular the use of .mxinfo files to declare a
> >component's JMX interface
> >
>
> No.
>
> JMX support in Merlin is ... "preliminary". You can startup
> merlin as a
> jmx server and via a jmx client invoke shutdown and
> redeployment. This
> works just fine. The jmx related strategy covers three areas
> - (a) how
> to automate internal jmx handling of appliances (managers of
> component
> types) so that componet types become auto-managed relative to Avalon
> lifecycle interfaces, and (b) how to handle support for custom
> management interfaces, and (c) how to federate multiple
> merlin kernels
> via adapters to a single jmx server management point.
>
> In the first area there are some preliminary resources in
> place but it
> is largely testing phase at this time. The second area -
> which is the
> subject your concerned about can be addressed two ways:
>
> (a) use the existing phoenix source code and build into merlin the
> equivalent functionality
> (b) use the qdox jmx solution with @jmx tags
>
> Either direction presents a few problems. Using the qdox solution we
> run into problems with their maven plugin which appears to be doing a
> really strage bunch of things that at the end of the day are not
> required - but their ant task works fine. Taking this approach would
> require that we write a maven plugin for the qdox jmx tag
> handler. But
> it would be better if the guys from Qdox did this! Going the phoenix
> style means replicating content that will probably (?) come
> from qdox.
>
> At the end of the day we need a jmx plugin for maven and from the
> artifacts generated, we need merlin to register and
> dererigister those
> management access points as required.
>
> Cheers, Steve.
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] jmx support
Posted by Stephen McConnell <mc...@apache.org>.
Jim Alateras wrote:
>Is there anything in Merlin today that parallels JMX support in Phoenix,
>in particular the use of .mxinfo files to declare a component's JMX
>interface
>
No.
JMX support in Merlin is ... "preliminary". You can startup merlin as a
jmx server and via a jmx client invoke shutdown and redeployment. This
works just fine. The jmx related strategy covers three areas - (a) how
to automate internal jmx handling of appliances (managers of component
types) so that componet types become auto-managed relative to Avalon
lifecycle interfaces, and (b) how to handle support for custom
management interfaces, and (c) how to federate multiple merlin kernels
via adapters to a single jmx server management point.
In the first area there are some preliminary resources in place but it
is largely testing phase at this time. The second area - which is the
subject your concerned about can be addressed two ways:
(a) use the existing phoenix source code and build into merlin the
equivalent functionality
(b) use the qdox jmx solution with @jmx tags
Either direction presents a few problems. Using the qdox solution we
run into problems with their maven plugin which appears to be doing a
really strage bunch of things that at the end of the day are not
required - but their ant task works fine. Taking this approach would
require that we write a maven plugin for the qdox jmx tag handler. But
it would be better if the guys from Qdox did this! Going the phoenix
style means replicating content that will probably (?) come from qdox.
At the end of the day we need a jmx plugin for maven and from the
artifacts generated, we need merlin to register and dererigister those
management access points as required.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org