geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anita Kulshreshtha <>
Subject Re: Can we deal generically with container specific jsr77 statistics?
Date Thu, 08 Nov 2007 13:52:36 GMT
Please see
    To summarize, the question is whether Tomcat*Stats (and
Tomcat*StatsImpl) is a management interface or a tomcat interface. To
me, if it imports only management classes, it is a management interface
and its implementation which also imports ONLY management classes
belongs in g-management. 
    Given that all management interfaces and their 33 implementations
are in g-management, I do not think it is worth the effort maintaining
duplicate classes just for Jetty. I suggest that we move Jetty*Stats
classes to g-management for now. If we start having 2 EJB
implementations, 2 Transaction managers or 2 JMS providers, then we
should implement the alternative suggested by you. 

More inline...
--- David Jencks <> wrote:

> There's been some discussion on
> GERONIMO-3586 and
> about how to deal with the jetty and tomcat jsr77 statistics.  It  
........................... an idea to 
> suggest that might keep the container specific code in the containers
> and allow management code to avoid needing any container specific  
> classes.

    These implementations DO NOT need any container specific classes. 
Until we come across one that needs one, we should put them in

.................  IIUC the  
> problems start when you try to send e.g. a JettyWebConnectorStatsImpl
> over the wire to a monitoring app, and the object can't be
> deserialized.

   Yes, and we must make sure that all StatsImpl (standard and geronimo
specific) are available via g-management to someone who might want to
write a stand alone client, use jconsole or any similar tool to get to


> I suggest we have in geronimo-management a StatsImpl class similar to
> the existing one but taking the name-statistic map in its constructor
> and being immutable.
> Then the jetty/tomcat specific stats classes won't implement Stats at
> all but just the container specific method.  Instead of extending  
> StatsImpl they will delegate to an instance they create in their  
> constructor.
> The MEJB can return the delegate StatsImpl objects, thus avoiding any
> need for any container specific classes, and the container specific  
> adapters can be in with the containers.
> Comments?
> thanks
> david jencks

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

View raw message