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]
