Laurent Rieu wrote:
I'll give the extended lifecycle extension a try to have ModelMBean
dynamically generated based on meta-info. Just a question : is it possible
to provide additionnal meta-info (generic meta-info facility) or do I need
to update Merlin for that ?
The updates need to go into the org.apache.avalon.meta package.
meta-spi package: org.apache.avalon.meta.info.Type
The Type class is the root of the type meta info object model. This is the object from which application can read information such as dependencies, published service, context criteria, etc. Management information needs to be added in the form of something like a new class ManagementDescriptor which would be included as a state member of Type.
meta package: org.apache.avalon.meta.info.builder.XMLTypeCreator
This class creates Type instance based on a supplied XML description. It reads in the tags and constructs all of the descriptors that make up a Type. To add JMX descriptors we will need to define the corresponding XML, include it in the Type DTD and update XMLTypeCreator to read this information in when building a type instance.
meta-tools package: org.apache.avalon.meta.info.builder.XMLTypeWriter
The takes an instance of Type and writes it out as an XML files. This will need to be updated to handle the externalization of a ManagementDescriptor to XML. This would include the definition of the corresponding javadoc tags.
This was originally put together as a meta package that would deal with the complete set of concerns across all containers. It is hosted under the avalon-sandbox/merlin project, however, don't let this confuse you into thinking that is Merlin specific - in fact the spi dependencies are limited to the Avalon framework, the meta package (the builder classes) dependencies only include i18n and excalibur configuration, and the meta-tools package includes the additional qdox and ant dependencies.
I think such a generic facility would be really
useful and can be made container-agnostic so that all containers could use
it and leverage it to provide additional features such as this dynamic
MBean generation.
Going generic is the only long term viable approach. With development based on the org.apache.avalon.meta package we can focus on migrating containers towards this. Phoenix is already very close and updating Fortress would be relatively easy as its meta-info usage is relatively small at this stage. However, the interest in doing this needs to come from the Fortress and Phoenix developers. Doing things like building above the meta package we are simply builds the case for other containers to leverage a common model.
I'll try to send you something (both working code and thoughts about JMX) next week !
Have you had a chance to look at the JMX Remote Specification (EA 1.0)? This is basically defining the management aspects I have in mind relative to a network of distributed Merlin runtimes.
Also on the subject of distributed runtime management, I think the guys on the James project will be rather interested in a solution that would allow decomposition of the James system across multiple JVMs while maintaining a simple logical management view.
Cheers, Steve.
--
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]
