Achim Huegen wrote:
At first we should discuss if it makes sense to publish threaded or pooled services as Mbeans. IMO the answer is clearly negative for threaded services, since their lifetime
is much to short to manage them.
What about pooled services? Are there management use cases for them?
You are right. We can ignore the threaded service model.
And for the pooled service model, I think we should threat all instances of a pooled service as one MBean. If the user would like to change an attribute of a pooled service, the new value should apply to all instances. For the operations, we should only list the operations defined in its service interface in the MBean. Other operations defined in its MBean service (if has) should be hided as we cannot know if those operations should be invoked in one of the instances or all instances. And the MBean of the pooled service should include pool attributes such as the # of active instances, the # of pooled instances, etc. What do you think?
If we concentrate on singletons it would be rather easy to keep a referenceThe special MBean can either be a DynamicMBean or a ModelMBean (optional in 1.1 and manadatory in 1.2).
to the core service implementation in the servicePoint.
Regarding the publishing of 'all attributes of a service object' I can
imagine multiple ways of registering a singleton service as mbean:
- specify the management interface in the mbeans contribution
- if no management interface is specified: automatically detect whether
the DynamicMBean or a standard mbean interface is supported
- specify that all attributes and operations of the service should
be exposed in the mbean. This will require a special mbean that uses introspection.
Eric
Achim Huegen
Hi,
Your prototype is quite impressive as they can show both the configuration points & service points as MBeans.
But as your remark says, we need to find a way to expose the core service object as MBean because the core service object can have more attributes and operations than its interface. And we should be able to access all attributes of a service object defined in the hivemind.xml file, not just the ones defined by its interface.
I would suggest to add an attribute to the service point MBean and this attribute should store the ObjectName of the core service MBean. And we can navigate from the service point MBean to its core service MBean. In order to do this, we need to have Hivemind's support to get the core service object of a service. The ServicePoint interface will be the appropriate place to get the core service object. But this changes also involve the ServiceModel objects as the ServicePointImpl object gets the service from one of the ServiceModel. It becomes rather complicate for the pooled and threaded service model and I have NO ideas how to do that.
BTW, I have extended HiveMind (using AspectJ) to register the core service objects as MBean after their instantiation (only for the primitive & singleton service model). But this extension only works for the core services, it does not include its interceptors.
Eric
Achim Huegen wrote:
Hi,
I invested time in building jmx support into hivemind. Some documentation and links to a working prototype are available here: http://wiki.apache.org/jakarta-hivemind/JmxPreview
I'm interested in feedback especially about the 'metadata' support.
Bye Achim Huegen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
