> functionality. This could define a public API which the management
> tool could use to retrieve the management data. It could also
> optionally persist this info to a database.
Yes. We need to be able to determine where the data ends up (in some
deployment descriptor), so that it could work
in environments without database or where the user wants the data in a
different place. I am also not yet completely sure what the best way
for JBossON/RHQ is to gather the data. DB tables sure are
Hello,
this slightly touches the idea, I proposed when discussing the
FragmentCache implementation (which I still haven't finished - sorry for
this).
What I did write was a Seam component where any other component can
register a statistic generator. When I want to print statistics of my
application,
I just call this central component and it will call all registered
statistic generator. In that case there are just normal Cache statistics.
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).
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, ...
Best Regards
Sebastian