Thanks Aaron. That makes a lot more sense (and is a lot easier) than
what I was trying to do with the GBean.
I'll complete the jetty impl first while I try to figure out how to
gather/enable/disable/reset the tomcat stats.
Joe
Aaron Mulder wrote:
The Stats shouldn't be a GBean, just a Serializable POJO holding the
values. And it wouldn't have the start/stop/reset stuff on it either,
that would go on the parent as a custom API addition (though we could
of course add it to the Geronimo WebContainer API or whatever).
Basically the owning GBean just hangs on to a POJO, and updates it and
gives it out when neccessary. Take another look at the Stats
implementation in JVMImpl. So I'd expect it to go something like
this:
SomeWebContainer {
private SomeWebStats stats;
public Stats getStats() {
if(stats == null) stats = new SomeWebStats();
stats.setRequestCount(...);
stats.setErrorCount(...);
...
return stats;
}
public void resetStatistics() {
stats = null;
}
}
As far as Tomcat goes, can you look at the code for Tomcat's web
console and work with Jeff Genender on duplicating that statistics
gathering in Geronimo? I seem to recall they create their components
as MBeans and then query them through JMX to gather statistics, but
I'm not really sure how that would work in the Geronimo environment.
Thanks,
Aaron
On 11/23/05, Joe Bohn <[EMAIL PROTECTED]> wrote:
Aaron,
After a long diversion on other items, I'm looking at the web server
statistics portlet and management api again. I was starting to expand
upon the structure that you began so that the Web Servers will report
statistics in a similar fashion to J2EE-Objects as specified in JSR77.
But I'm not sure how we should implement some capabilities:
What I've done thus far:
- I added a marker interface for JettyWebContainerStats extended from
WebContainerStats. I updated JettyWebContainerStatsImpl to implement
both the JettyWebCOntainerStats interface and the GBean-LifeCycle. I
updated the plan to add this gbean into the configuration. I also
updated the JettyContainerImpl to return true for isStatisticsProvider.
I haven't done the tomcat version yet, but it will follow the same
pattern. I can begin collecting statistics from Jetty during the
initialization of the JettyWebContainerStatsImpl GBean and get the
necessary statistics information from the Jetty Server ... but of course
this has some performance implications (see below).
Problems/Questions:
- First, am I staying true to your intended implementation?
- There doesn't seem to be an equivalent notion of enable/disable/reset
in the JSR77 Statistics Provider design. I think I must be missing
something because this seems like an obvious requirement. Without this
we would be collecting statistics for the web container continually and
thereby impacting performance. I can also see why reset would be valuable.
- I still don't have an idea on how to collect similar stats data from
Tomcat without creating our own implementation to monitor and collect
the data. Therefore, my first pass was going to be just getting Jetty
working with a message that this is not yet implemented for tomcat. If
we get some more information on tomcat prior to V1 release we would add it.
Given all that, the result to the end user would be pretty much
unchanged from what we currently have with the portlet that is
hard-wired for jetty only. The one big difference (aside from the
structural improvements) would be that the enable/disable/reset would be
removed and we may be hitting performance problems if we do not extend
the JSR77 design (of course this is moot if I'm just missing it).
So, as we approach V1, do you think we should spend time on this now or
should I focus on something else?
Thanks,
Joe
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
