Re: [merlin] jmx support

[Stephen McConnell]

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:[EMAIL PROTECTED] 
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:[EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]