Hi,
I already played around to register the component as a normal JMX
to allow using it with the JMXConsole.
This is a inverse approach as compared to your idea (pulling of
statistics) as opposed to pushing it somewhere (in memory or
database).
Not really. JBossON / RHQ can read stuff like logfiles, but for
measurement purposes, this is not optimal.
So putting the data into an MBean from where we regularly pull it, is
pretty ok. And with JavaSE5+ having an
MBeanServer in it, this could even be a general approach.
> Still IMHO we should define a common approach here.
> Any kind of statistics could be interesting - Response
Time, Number
> of dialogs, average dialogs per session, ...
Yeah.
From my point of view (being not too Seam-savvy) it is important
that this stuff is easy to add to an
application to be usable.
The other thing to keep in mind is that Resources that get identified
within the application need to have
an unique key. For metrics, we can define "static" ones meaning that
those are some that are always present
(e.g. stuff like cache hits of a global seam-like cache or average
time spent in the seam interceptors or such).
And then we can have "dynamic" metrics in the sense that they get
determined at runtime like we currently to
for http response time data (this is keyed by the Url where the key
does not need to be known at compile
time).
Heiko