[ 
https://issues.apache.org/jira/browse/GERONIMO-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540957
 ] 

Anita Kulshreshtha commented on GERONIMO-3586:
----------------------------------------------

 Prasad,
   The (tomcat) Stats and StatsImpl in question are _management_ interfaces. 
There is NO CONTAINER SPECIFIC code in them. They do not
need container code to compile. These are no different than EJBStats,  JTAStats 
or many other Stats in g-management package.  
The same should be true for Jetty. This is why I propose that we move the 
Jetty*Stats* to g-managemnt. 
Joe,
     We need to distinguish between the server the tool is running on and the 
server that is being monitored. Yes we can have two versions of the 
tool (just like console). But that does not mean that a tool running on tomcat 
can not monitor a server instance running on Jetty.  An important
difference between admin console and monitoring console is that admin console 
administers the server it resides on, but a realistic monitoring console NEVER 
monitors the server it resides in.
     I hope this is helpful.   

> monitoring plugin: collecting agent should have separate jetty and tomcat 
> plugins
> ---------------------------------------------------------------------------------
>
>                 Key: GERONIMO-3586
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-3586
>             Project: Geronimo
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: monitoring
>    Affects Versions: 2.1
>         Environment: windows
>            Reporter: Viet Hung Nguyen
>            Assignee: Jarek Gawor
>         Attachments: geronimo-3586.patch
>
>
> The collecting agent plugin needs to have separate jetty and tomcat plugins 
> in order to accommodate for the differences in container specific 
> dependencies on stats implementation (.e.g JettyContainerStatsImpl and 
> JettyConnectorStatsImpl). When the collecting agent was an EAR, this was not 
> a problem; however, as a plugin, it is more tied down to having to specify 
> all dependencies in the plugin's classpath.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to