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?
An idea that came to my mind too. We would need a service instance creation event, that is dispatched by the servicePoint or model to
get references to all service instances.
But the the amount of operations that can be called automatically on
all instances is small. Getters can't be handled reasonably.
Even non-void methods in general are problematic.
Another option would be to build some infrastructure that allows easy creation of custom mbeans that handle multiple services instances:
- automatic registration of service instances in the mbean
- support for calling methods in all instances
- support for calling getter/non-void methods in all instances and
getting an array of result objects
Of course it is more work to implement a custom mbean, but it is the easiest way to decide which methods are called which way. For example the mbean could calculate the sum or average of all the values that are returned by a certain getter method.
Achim Huegen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
