We want JMX (or something) for configuration/administration as well as
maintenance/monitoring.  What you described with the management of the
deployment model in Merlin would mostly solve our problem, but we still need
the ability to define an interface for monitoring type methods.  This sounds
like the JMX extension you mentioned.

One of the limitations we have run into with Phoenix's JMX is that there is
no access to the SystemManager, so when developing "Selector" type blocks
that are containers for components, there is no way to use the "JMX magic"
in Phoenix to create MBeans for these sub-components. I am hoping with
Merlin's container model we can get around both the lack of access to the
SystemManager but also the need to manually run these sub components through
their lifecycle using ContainerUtil.

Anyhow, I am looking forward to trying out our stuff under Merlin 3.0 to see
how it is.  Thanks again!

-Cameron

-----Original Message-----
From: Stephen McConnell
To: Avalon Developers List
Sent: 8/17/03 2:49 AM
Subject: Re: [MERLIN] Re: Announcing Loom / Phoenix forked



Cameron Fieber wrote:

>I am currently in the process of trying to get our development team
into
>the Avalon component world, and Phoenix has been fairly key in my
>ability to "sell" it to the rest of the team, as well as justifying the
>effort to the people in charge of my time.
>

Yep, I understand.  Could you give me a little bit more information
about
your usage of JMX.  Are you mainly coincerned with simple startup and 
shutdown
of components or are you doing extra stuff beyond this?  The reason I'm 
asking
is that I've been playing with a solution that would (in prinncipal)
enable
complete JMX management of the entire delployment model (config, 
parameters,
context, deployment and decommissioning) simply using facilities inside
the
container. 

>
>I am keeping an eye on Merlin as the future container for our stuff,
but
>for now the ability to bring up a JMX management console for our blocks
>is getting buy in from the management types and operational types. 
>AFAIK the JMX (or whatever component management) stuff in Merlin is a
>high priority @todo but not there yet?
>

There are a set of JMX facilities in place in the 
avalon-sandbox/merlin-test directory.  Unfortunately I've recently 
broken the JMX example as a result of putting in place stricter 
container/component classloader seperation.  To get things back and 
demonstatable I need to update the demo so that the extensions are 
seperate from the components, and provide a mechanism for declaring a 
jar file containing the extensions to the kernel.  Once that is in place

you would be able to use a pluggable JMX extension handler.

In the meantime there is always the possibility of declaring a JMX 
server as component and linking to this as a regular service (it works, 
the code is already in-place, just not the most elegant solution).

Stephen.

>
>Regards,
>
>-Cameron
>
>On Thu, 2003-08-14 at 15:49, Stephen McConnell wrote:
>
>  
>
>>I would like to let everyone in the Avalon development and user 
>>community know that the existing investment into the avalon framework 
>>and Phoenix product will be supported under the Merlin platform.  In 
>>particular, the Merlin platform has been supporting Phoenix components
>>since version 2.1.  The current codebase under version 3.0 will allow 
>>even stronger support for some of the more obscure Phoneix features
>>and 
>>capabilities.
>>
>>Perhaps more importantly, the Merlin platform will ensure a smooth 
>>migration path that will respect the Avalon framework interface (as 
>>opposed to the fork of the framework proposed by Loom project).  As
>>part 
>>of the process of supporting the user base, I encorage everyone to 
>>please let us if and what specific Phoenix features you are using.  It
>>is clearly in our interests to ensure that there is a functional 
>>migration path open to our users.
>>
>>Currently on my development list are the following topics: (a) support
>>for the notion of block listeners (as part of a a larget model 
>>management objective; (b) incorporation of a security policy
>>declaration 
>>(also under the scope of meta model management); (c) inclusion on
>>Maven 
>>and Ant tools supporting configuration validation.
>>
>>If there are other aspects - please let us know.
>>
>>Cheers, Steve.
>>
>>-- 
>>
>>Stephen J. McConnell
>>mailto:[EMAIL PROTECTED]
>>http://www.osm.net
>>
>>Sent via James (declared as a suite of Phoenix components) using
>>Cornerstone components (mapped using existing Avalon Meta legacy
>>management tools) under Merlin 3.0 running as an NT service.
>>
>>http://avalon.apache.org/sandbox/merlin
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>    
>>
>
>  
>

-- 

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
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]

Reply via email to