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