Simone,
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.
--=20
=C9amonn
Bordet, Simone wrote:
> Hi,=20
>=20
>=20
>>OK. The caller knows that when start() returns it can call=20
>>the methods.=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
>>MBean will=20
>>be stopped in the meantime. =20
>=20
>=20
> This happens in any server-side component that is "remoted", for exampl=
e any
> RMI server, doesn't it ?
>=20
>=20
>>Likewise, the fact that you see a method in=20
>>the MBeanInfo doesn't mean that you can call it because it=20
>>can disappear.
>=20
>=20
> Sure. This is implicit in the "dynamic" management interface.
> The specification must specify exactly what exception one should expect=
, so
> the client can catch it and re-query the MBeanInfo. Eventually, it can
> complete the call, or give the user an indication.
>=20
>=20
>>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
>>or operation=20
>>as disabled. This would allow you to gray it out in a GUI,=20
>>for example.=20
>=20
>=20
> This looks like something implementable only by ModelMBeans, and I am a=
bit
> 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.
>=20
>=20
>> It might be better to disable the attributes and operations=20
>>when the MBean is not running than to delete them.
>=20
>=20
> 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=
be
> 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=
or
> RMMB.
>=20
> Regards,
>=20
> Simon
>=20
|