David, Please see https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957 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 <[EMAIL PROTECTED]> wrote: > There's been some discussion on > https://issues.apache.org/jira/browse/ > GERONIMO-3586 and https://issues.apache.org/jira/browse/GERONIMO-3587 > > 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 g-management. > ................. 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 stats. Thanks Anita > > 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 http://mail.yahoo.com
