I *think* there are only four MBean types (Standard, Dynamic, Open,=20
Model). Though if we add MXBeans that will make five. Perhaps that's=20
what you're thinking of.
My thinking was simply that in the MBeanAttributeInfo and=20
MBeanOperationInfo classes we could have a settable boolean field=20
"enabled". When you construct an MBeanInfo you decide for each=20
attribute and operation whether it is enabled. A DynamicMBean can=20
return different MBeanInfos at different times, where the contained=20
attributes and operations change from being enabled to being disabled=20
and vice versa.
Bordet, Simone wrote:
>>OK. The caller knows that when start() returns it can call=20
>> But if you call isStarted(), you have no guarantee that you will=20
>>subsequently be able to call the methods, because maybe the=20
>>be stopped in the meantime. =20
> This happens in any server-side component that is "remoted", for exampl=
> RMI server, doesn't it ?
>>Likewise, the fact that you see a method in=20
>>the MBeanInfo doesn't mean that you can call it because it=20
> Sure. This is implicit in the "dynamic" management interface.
> The specification must specify exactly what exception one should expect=
> the client can catch it and re-query the MBeanInfo. Eventually, it can
> complete the call, or give the user an indication.
>>Nevertheless, this is a simple example, and it might be worth=20
>>adding it to the spec.
>>Relatedly, bug 4786777 calls for a way to mark an attribute=20
>>as disabled. This would allow you to gray it out in a GUI,=20
> This looks like something implementable only by ModelMBeans, and I am a=
> worried. If not already complex enough, I would avoid making the poor
> ModelMBean method carry a Map where:
> if a then A, else if b then B, else if c then C, etc etc etc.
> Management user interface writers will have a difficult time.
>> It might be better to disable the attributes and operations=20
>>when the MBean is not running than to delete them.
> If you can do this for DynamicMBeans, I may agree. Otherwise, it seems
> specific to ModelMBeans, which is only one of the 5 MBean types. It may=
> suggested but not carved in the stone by writing it in the spec.=20
> And I guess very few use the RMMB, so I'm very dubious in defining it f=