5.0 and jmx

[Costin Manolache <cm...@yahoo.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: 5.0 and jmx

[Costin Manolache <cm...@yahoo.com>]

Glenn Nielsen wrote:

> There are now several commerical tools for doing production runtime
> monitoring of java applications which can obtain their data using JMX.

That's orthogonal - it doesn't matter what method we use to 'jmx-enable',
what matters is to have the getters for the info we need. That's quite
easy to do ( except for timing and performance data - where we have
to avoid sync - but be thread safe - that will need some thread tricks ).

> 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.

+1

> 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 think adding getters to the components that have the information
is the easiest ( and best ) solution. 

This is really not very dependent to JMX - it doesn't matter if you
define the MBean interface directly, use dynamic or model mbeans. What 
matters is to have the information available, wrapping in JMX is extremely
easy.

Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: 5.0 and jmx

[Glenn Nielsen <gl...@mail.more.net>]

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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>