aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siqi Du <>
Subject Re: Mbeans for Blueprint
Date Thu, 19 Nov 2009 07:57:03 GMT
I also feel it is not very graceful to use containerServiceId  every
time. In common cases there are several container services and a
single extender service. Maybe it is better to distinguish the mbean
for blueprint extender  from the mbean for a blueprint

> 2009/11/19 Alan Keane <>
>> Hi,
>> The interfaces defined look good to me both in terms of usefulness and
>> consistency with RFC-139.
>> The BlueprintMetadataMBean supports querying of the metadata based on
>> containerServiceId and componentId so I don't think
>> we would have any need for a single MBean for each BlueprintContainer
>> service.
>> If required it would be relatively straightforward to extend the JMXAgent
>> to
>> discover and manage the lifecycle of these or
>> other additional MBeans for compendium services.
> Yes. I agree.
> I see the RI using an acivator to register the MBeans to mbean servers. I
> don't very like such implement. If your jmx agent can be published as a
> service,  the bundle of blueprint mbean implement can leverage such service
> to register its mbean to all the servers.  That is, the new mbean bundles
> don't need to implement another jmx agent itself. On the other hand, as you
> state above, including the blueprint mbean implement  in our Aries' 139
> imlpement bundle and extend the JMX agent is a good approach.

View raw message