On Dec 27, 2006, at 4:56 PM, Meeraj Kunnumpurath wrote:
Hi,
I have updated standalone server to support multiple runtimes. Now,
when the server is started, it doesn't start any runtime. However,
the server has a management op called startRuntime(String bootPath)
to start a runtime. Boot path for the runtime is resolved relative
to the installation path. It is expected to have a file called
runtime.properties in a directory named etc.
The file contains the JMX domain name under which the runtime
instance is registered. Once started the runtime instance is
available for management. Only management ops currently available
are initialize and destroy.
This allows any number of runtimes to be started within a server
environment.
Good stuff.
This got me thinking about registering Components with JMX so that
they too can be managed.
One thought was about generating an ObjectName for each component
that we know will be unique whilst sticking with some of the
recommendations for naming here:
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/
best-practices.jsp
I think allowing the user to determine the JMX domain name makes
sense - that allows them to know for sure which TuscanyRuntime they
are dealing with. If we go this way, we only need to set naming
conventions for the keys.
In SCA every component has a unique QName comprising of the URI of
its containing composite and the local name within. Therefore we can
create a unique name for the MBean of the form:
${userDomain} : type = SCAComponent, composite = "${compositeURI}" ,
name = ${componentName}
We also have Tuscany-specific system components and I'd suggest for
those we use type = TuscanySystem
Rather than use hierarchical type values, this uses the natural
hierarchy of the composite URI to express containment. Because the
URI is likely to contain a scheme the value needs to be quoted to
escape the ':'
The other thought was about how a component could expose a management
interface. One option would be to support <binding.jmx> for
attachment to a service; however, this would require a componentType
sidefile. Another would be to support an @Management annotation on a
service interface. With both of these the selected service would be
registered as a Dynamic MBean. A fallback option would also be to
recognize the component as a Standard MBean (i.e. it would have a
*MBean interface).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
