Remember that statistics shouldn't be in the GBeans anyway. I
think the JVMImpl is the only one that does this correctly. The
GBean should cough up a Stats object (like JVMStats or EJBStats or
whatever) that contains a bunch of Statistics properties. So the
only method on the GBean is the "getStats". I have a huge todo
list of all the Stats stuff we need to implement properly on the Wiki
on the page http://wiki.apache.org/geronimo/Web_Console
Also, our definition of "manageable" is not "only manageable properties appear in the management API" but "only manageable properties can be changed in the management API". You know, even if you've locked down certain properties, I think the admin should be able to *see* their values.
David Jencks wrote:
> Can you explain how saving statistics values between server stop/starts
> is meaningful? Could be, but I don't understand how yet. I basically
> don't know anything about how people gather server statistics.
> Maybe calling this "manageable" is not quite the right term?
Obviously they aren't persistent, but they do need to be managed
otherwise they are not viewable.
I think there are three things here:
* persistent - value can be saved in the bundle
* configurable - value can in overridden by attribute store
* managed - value should be exposed to management (e.g. JMX)
* Statistics are managed but not persistent.
* Config properties are configurable and probably managed.
* Interceptor stacks are persistent but not configurable or managed.
* Runtime properties (e.g. $resource) are none.