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

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.


On 9/20/05, Jeremy Boynes <> wrote:
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
   (implies persistent)
* managed - value should be exposed to management (e.g. JMX)

For example:
* 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.