From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Standalone server
Date: Thu, 28 Dec 2006 09:43:12 -0800
On Dec 28, 2006, at 8:20 AM, Meeraj Kunnumpurath wrote:
Hi,
What I have done for the time being, is to use DynamicMBean and
reflection to expose any POJO as a managed bean. It is in
org.apache.tuscany.standalone.server.management.jmx.instrument.reflect
.ReflectedDynamicMBean. By default it excludes methods and properties on
java.lang.Object. There is an overloaded factory method to exclude
further methods and properties from the management interface. Currently
all the JMX stuff are in server.start module. I think we will have to
move this to somewhere else, may be spi?
Also, when the runtime is registered in the JMX domain, would we want to
register all the components in the system tree as well?
I agree with Joel's goal of having this as unintrusive to application code
as possible - the reflection based approach there is a good start but I
think we should take it further by allowing a user (if they want to) to
choose which methods are "management" operations as opposed to normal
application operations.
How that description is done is really part of the component programming
model so I would suggest moving that to the appropriate container
extensions (primarily the java and system containers for now - it's
probably common to both).
Would the components annotate the ops and properties as part of the
management interface? Wouldn't that be a bit too intrusive? An alternative
would be to use model mbeans and extrenalized descriptors?
Once we have the description, then I think it should be the responsibility
of the fabric to handle how the component gets bound to the management
framework. This would mean we get management support for any container
that can do the introspection, and it means that we can isolate which
management framework is being used (JMX, WSDM, SNMP, ...)
We can do this by adding a ManagementService to the runtime (interface in
SPI, null and JMX impls as core services) and extend the register() method
on CompositeComponent to register new components with it.
Can we have ManagementService autorired into CompositeComponent. Also, we
can decouple the management fabric from the agent connector that exposes it
to management clients. However, this should be opaque to the component
programming model.
Something like:
interface ManagementService {
registerComponent(URI compositeURI, String name, Component component)
}
interface Component {
...
void setProperty(String name, Object property)
Object getProperty(String name);
}
This would result, at least, in the SCA properties of the component being
exposed as management properties. This needs to be done by the component
container so that management operations set/get the properties the
container is using rather than the instance (to handle scopes properly).
It would be the container's responsibility to update active/pooled
instances.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters!
http://www.msn.co.uk/newsletters
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
