Re: Can we deal generically with container specific jsr77 statistics?
I believe Anita is correct on this one. The specs define that we need the getXYZ() methods for each statistics named XYZ. At this point, I think we need to move forward with a decision a) put everything in g-management or b) split jetty/tomcat stats apart. As for me, I say let's just go with option A. In order for the monitoring plugin to work on both assemblies this issue needs to be resolved. If we plan on releasing the monitoring plugin with 2.1, we'll need to have time to test it on both assemblies. Thanks, Viet
Re: Can we deal generically with container specific jsr77 statistics?
On Nov 19, 2007, at 7:33 AM, Viet Nguyen wrote: I believe Anita is correct on this one. The specs define that we need the getXYZ() methods for each statistics named XYZ. At this point, I think we need to move forward with a decision a) put everything in g-management or b) split jetty/tomcat stats apart. As for me, I say let's just go with option A. In order for the monitoring plugin to work on both assemblies this issue needs to be resolved. If we plan on releasing the monitoring plugin with 2.1, we'll need to have time to test it on both assemblies. After reading Anita's explanation I agree A is the way to go. Sorry for the apachecon delay in responding. thanks david jencks Thanks, Viet
Re: Can we deal generically with container specific jsr77 statistics?
IIUC, you are saying that the container specific StatsImpl will have the extended map to define extra statistics, but getStats() will return generic StatsImpl. JSR77.6.10.1.1 requires that for every statisitc named XYZ, there must be a method named getXYZ to get the value of the statistics. In other words adding statistic to the map is not enough. More inline... --- David Jencks [EMAIL PROTECTED] wrote: 1. Only generic interfaces in g-management, and we pretty much insist that clients use the generic interfaces only. If they want something else its up to them to figure out how to find it, and it might not exist. If we tell the client that a component is a statisticsProvider, than it must provide getStats() in accordance with JSR77.6.10.1.1. 2. Only generic interfaces in g-management, specific interfaces in the component modules (such as jetty/tomcat) and we expect clients to use the specific interfaces, thus they will need to import the component modules to get the interfaces That would certainly make using any other tool a bit harder than it needs to be. One must figure out where all the StatsImpl that could possibly be supported by geronimo are defined, and put all the jars on the classpath. 3. Specific interfaces in g-management, and we expect clients to use the specific interfaces. I am all for this :). I am looking forward to a convincing argument for not choosing this. Thanks Anita Hope this clarifies what we are talking about. david jencks thanks david jencks Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
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. I noticed that in the JSR 77 spec, the generic classes such as EJBModuleStats extends Stats. Meaning the EJBModuleStatsImpl will extend StatsImpl, the way things are with the Jetty/Tomcat specific stats right now. So if we took the specific Jetty/Tomcat stats code (something that is not defined by JSR-77) and used the technique you suggested, David, do you think that will be a tolerable inconsistency? I have tested your idea and everything works fine. If there are no objections I can put a create a new jira along with the patch. -Viet Comments? thanks david jencks
Re: Can we deal generically with container specific jsr77 statistics?
--- Joe Bohn [EMAIL PROTECTED] wrote: Anita Kulshreshtha wrote: 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 stand corrected, 30 implementations. Thanks Anita Just to clarify the structure and the history: The standard Stats from the the JSR77 spec are in o/a/g/management/stats The generic Geronimo Stats which are extensions to the spec are in o/a/g/management/geronimo/stats Until recently, the o/a/g/management/geronimo/stats package only included generic stats classes (meaning they were not supposed to be specific to the implementation of the component such as Jetty or Tomcat). Jetty specific classes which extended these generic classes were in o/a/g/jetty and the intention was that tomcat specific classes would be included in tomcat. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
At the risk of getting caught in the crossfire here... So, lets say the classes for jetty or tomcat that extend those in o/a/g/management/geronimo/stats reside within same package... are we then saying that classes extending those for, say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? -Erik On Nov 8, 2007 9:31 AM, Joe Bohn [EMAIL PROTECTED] wrote: Anita Kulshreshtha wrote: 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, Just to clarify the structure and the history: The standard Stats from the the JSR77 spec are in o/a/g/management/stats The generic Geronimo Stats which are extensions to the spec are in o/a/g/management/geronimo/stats Until recently, the o/a/g/management/geronimo/stats package only included generic stats classes (meaning they were not supposed to be specific to the implementation of the component such as Jetty or Tomcat). Jetty specific classes which extended these generic classes were in o/a/g/jetty and the intention was that tomcat specific classes would be included in tomcat. Joe -- Erik B. Craig
Re: Can we deal generically with container specific jsr77 statistics?
Anita Kulshreshtha wrote: 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, Just to clarify the structure and the history: The standard Stats from the the JSR77 spec are in o/a/g/management/stats The generic Geronimo Stats which are extensions to the spec are in o/a/g/management/geronimo/stats Until recently, the o/a/g/management/geronimo/stats package only included generic stats classes (meaning they were not supposed to be specific to the implementation of the component such as Jetty or Tomcat). Jetty specific classes which extended these generic classes were in o/a/g/jetty and the intention was that tomcat specific classes would be included in tomcat. Joe
Re: Can we deal generically with container specific jsr77 statistics?
--- Erik B. Craig [EMAIL PROTECTED] wrote: say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? Since these classes ONLY depend on management classes and not on openEJB or somesuch, it does not affect the pluggable server/framework design. I do not think we are planning to strip down classes from g-management to cater to pluggable framework and add classes as we upgrade to a higher assembly. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
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
Re: Can we deal generically with container specific jsr77 statistics?
We do not control what openEJB or somesuch ship with. We need to make all StatsImpl available via g-management. Thanks Anita --- Erik B. Craig [EMAIL PROTECTED] wrote: At the risk of getting caught in the crossfire here... So, lets say the classes for jetty or tomcat that extend those in o/a/g/management/geronimo/stats reside within same package... are we then saying that classes extending those for, say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? -Erik On Nov 8, 2007 9:31 AM, Joe Bohn [EMAIL PROTECTED] wrote: Anita Kulshreshtha wrote: 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, Just to clarify the structure and the history: The standard Stats from the the JSR77 spec are in o/a/g/management/stats The generic Geronimo Stats which are extensions to the spec are in o/a/g/management/geronimo/stats Until recently, the o/a/g/management/geronimo/stats package only included generic stats classes (meaning they were not supposed to be specific to the implementation of the component such as Jetty or Tomcat). Jetty specific classes which extended these generic classes were in o/a/g/jetty and the intention was that tomcat specific classes would be included in tomcat. Joe -- Erik B. Craig __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
While I think that technically Anita is correct this approach produces some practical challenges. If all the *StatsImpl classes for all components in the server are gathered in g-management then how can the *StatsImpl classes be upgraded, modified, or replaced without also replacing g- management? The g-management module would become a major source of contention as various components fix and improve their management interfaces (and we hope they do). And since g-management is part of the core framework I think replacing it would require recycling the server (not verified). Let's weigh this out against the overhead of maintaining separate configs for each of the various assembly configurations, which is certainly no trivial matter. Best wishes, Paul On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote: --- Erik B. Craig [EMAIL PROTECTED] wrote: say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? Since these classes ONLY depend on management classes and not on openEJB or somesuch, it does not affect the pluggable server/framework design. I do not think we are planning to strip down classes from g-management to cater to pluggable framework and add classes as we upgrade to a higher assembly. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
I hadn't really thought about footprint issues, but that's a good point. Put another way, my concern is: Can a component's management interface be modified without also replacing g-mangement? Best wishes, Paul On Nov 8, 2007, at 11:56 AM, Anita Kulshreshtha wrote: --- Paul McMahan [EMAIL PROTECTED] wrote: While I think that technically Anita is correct this approach produces some practical challenges. If all the *StatsImpl classes for all components in the server are gathered in g-management then how can the *StatsImpl classes be upgraded, modified, or replaced without also replacing g- management? Paul, We are talking about few classes (e.g. 3 each for tomcat/Jetty) per component not few jars. I do not think it is worth having separate g-management for each assembly. Especially when we still ship all specs _jars_ in the smallest assembly. I hope this answers your concerns.. Thanks Anita The g-management module would become a major source of contention as various components fix and improve their management interfaces (and we hope they do). And since g-management is part of the core framework I think replacing it would require recycling the server (not verified). Let's weigh this out against the overhead of maintaining separate configs for each of the various assembly configurations, which is certainly no trivial matter. Best wishes, Paul On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote: --- Erik B. Craig [EMAIL PROTECTED] wrote: say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? Since these classes ONLY depend on management classes and not on openEJB or somesuch, it does not affect the pluggable server/framework design. I do not think we are planning to strip down classes from g-management to cater to pluggable framework and add classes as we upgrade to a higher assembly. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
--- Paul McMahan [EMAIL PROTECTED] wrote: While I think that technically Anita is correct this approach produces some practical challenges. If all the *StatsImpl classes for all components in the server are gathered in g-management then how can the *StatsImpl classes be upgraded, modified, or replaced without also replacing g- management? Paul, We are talking about few classes (e.g. 3 each for tomcat/Jetty) per component not few jars. I do not think it is worth having separate g-management for each assembly. Especially when we still ship all specs _jars_ in the smallest assembly. I hope this answers your concerns.. Thanks Anita The g-management module would become a major source of contention as various components fix and improve their management interfaces (and we hope they do). And since g-management is part of the core framework I think replacing it would require recycling the server (not verified). Let's weigh this out against the overhead of maintaining separate configs for each of the various assembly configurations, which is certainly no trivial matter. Best wishes, Paul On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote: --- Erik B. Craig [EMAIL PROTECTED] wrote: say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? Since these classes ONLY depend on management classes and not on openEJB or somesuch, it does not affect the pluggable server/framework design. I do not think we are planning to strip down classes from g-management to cater to pluggable framework and add classes as we upgrade to a higher assembly. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
On Nov 8, 2007, at 7:10 AM, Anita Kulshreshtha wrote: --- Erik B. Craig [EMAIL PROTECTED] wrote: say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? Since these classes ONLY depend on management classes and not on openEJB or somesuch, it does not affect the pluggable server/framework design. I do not think we are planning to strip down classes from g-management to cater to pluggable framework and add classes as we upgrade to a higher assembly. I agree with you that it is possible to include the Jetty/Tomcat Stats classes in g-management without pulling in any jetty or tomcat classes, and similarly all the named geronimo specific stats classes don't require classes from the components they are for. Similarly I think its pretty clear my proposal will work and clients can get the StatsImpl objects and deal with them by finding out what they support. I'm wondering if it is a good idea to expose classes that turn the set of Statistics exposed by some particular geronimo component into a type, or if it is a better idea for clients to use the generic interface. IIRC when we introduced these classes they seemed like a good idea but I'm wondering if they have any real use. AFAICT the classes names w/jetty/tomcat aren't used anywhere outside the jetty/ tomcat modules which makes me think that we should consider removing all of the non-generic types from g-management, starting with the Tomcat ones and continuing as time allows. So to me this is pretty much a philosophical question. I'm leaning towards only exposing generic classes. What do others think? Why is it a good idea to have the non-generic classes? thanks david jencks Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
On Nov 8, 2007, at 8:33 AM, David Jencks wrote: On Nov 8, 2007, at 7:10 AM, Anita Kulshreshtha wrote: --- Erik B. Craig [EMAIL PROTECTED] wrote: say, openEJB or somesuch would also reside here rather than within our openEJB package? If so, how would this all play into the pluggable server/framework design? Since these classes ONLY depend on management classes and not on openEJB or somesuch, it does not affect the pluggable server/ framework design. I do not think we are planning to strip down classes from g-management to cater to pluggable framework and add classes as we upgrade to a higher assembly. I agree with you that it is possible to include the Jetty/Tomcat Stats classes in g-management without pulling in any jetty or tomcat classes, and similarly all the named geronimo specific stats classes don't require classes from the components they are for. Similarly I think its pretty clear my proposal will work and clients can get the StatsImpl objects and deal with them by finding out what they support. I'm wondering if it is a good idea to expose classes that turn the set of Statistics exposed by some particular geronimo component into a type, or if it is a better idea for clients to use the generic interface. IIRC when we introduced these classes they seemed like a good idea but I'm wondering if they have any real use. AFAICT the classes names w/jetty/tomcat aren't used anywhere outside the jetty/tomcat modules which makes me think that we should consider removing all of the non-generic types from g- management, starting with the Tomcat ones and continuing as time allows. So to me this is pretty much a philosophical question. I'm leaning towards only exposing generic classes. What do others think? Why is it a good idea to have the non-generic classes? talking with pmcmahon I think there are 3 choices let me try to make them more explicit. 1. Only generic interfaces in g-management, and we pretty much insist that clients use the generic interfaces only. If they want something else its up to them to figure out how to find it, and it might not exist. 2. Only generic interfaces in g-management, specific interfaces in the component modules (such as jetty/tomcat) and we expect clients to use the specific interfaces, thus they will need to import the component modules to get the interfaces 3. Specific interfaces in g-management, and we expect clients to use the specific interfaces. Hope this clarifies what we are talking about. david jencks thanks david jencks Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Can we deal generically with container specific jsr77 statistics?
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 might be good to try to have such discussions on the dev list... I talked with Viet about this on IRC for a while and have 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. According to my IDEA project setup and Viet, the container specific interfaces and implementations are only used inside the jetty and tomcat containers to make it easier for the container to update the statistics. They are not used in the monitoring plugin. 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. 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
