Heiko W.Rupp schrieb:
> 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.
MBean seams a reasonable
approach, it is quite simple to setup and we
could create a kind of management package in seam where all kind of
mbeans to inform or to manage a seam app are packaged.
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
Do you want to have real data or reports (as a simple String) for your
JON? I assume real data, as you can place rules etc in JON to react.
In that case, will you create a kind of stub for every metric MBean we
provide or do we need a generic approach, where we define something like:
name: response time
data type: long
A generic approach (as always) requires a larger effort.
Could you provide some use cases, what you want to pull, regularly or
once, raw data (response time) or 'manufactured' data (e.g. average