There are now several commerical tools for doing production runtime monitoring of java applications which can obtain their data using JMX.
Currently JMX in Tomcat is only being used for configuration data. I would like to see this expanded to support making available production runtime monitoring data. With that in mind, I would like it to be easy to plug in an MBean anywhere it might be useful to export metrics on tomcat performance and usage of resources to the outside world. I had planned on looking into this more when I have time in December. Just thought I would throw this out so it can be considered as you discuss the below. Regards, Glenn Costin Manolache wrote:
Not sure if this was decided or we are just in a status-quo mode.
My question is what is our position regarding the dependency of
tomcat5 on JMX and the level of integration/support.
There are 2 choices:
- 5.0 requires JMX. If this is the case we can have code that takes
advantage of this a bit more.
- 5.0 doesn't require JMX, but it can be jmx-enabled using listeners
and the modeler.
In both cases I think it is essential to make few changes - like letting
the components know their own name and moving some of the logic
that is now in mbeans/ package back to the components.
For most cases it is possible to do that using some wrapper - like
the new BaseRegistry I added to modeler ( unless someone -1 it :-)
The problem I am trying to solve is the relative difficulty of
adding new mbeans ( the MBeanFactory, the xml file, etc). If nobody objects I would like to move the descriptor to META-INF
and use getResources() to load all descriptors - I added some of the code in modeler.
A second change would be to add a mechanism to deal with the MBeanRegistration - for example using some methods with the
same name ( preRegister, postRegister, etc) that could be hooked with
the current lifecycle. The hooks could be used to implement the logic that is currently in the MBeanFactory in the real
object ( for example have a LogValve register itself with the
Context/Host/Container ).
It is not very difficult to wrap most of the JMX functionality ( either in BaseRegistry or in a JNDI context ). We need registration, location of
components and callbacks. Of course, using JMX directly would simplify
some code.
Craig, Amy, Remy - I would apreciate feedback on those issues.
Costin
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
