geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Using JMX, was: Spring integration...
Date Wed, 09 Feb 2005 05:45:59 GMT
Bruce Snyder wrote:
>> ??? lost you here - are you saying rewrite Tomcat and Jetty because
>> they implement the standard J2EE management interface and Geronimo
>> doesn't ?
> The statement above is absolutely correct!

No it isn't. Geronimo DOES implement the standard J2EE management 
interface. It has to, its part of the spec.

> Geronimo is the long pole in the tent here. The two examples we're
> discussing (Jetty and Tomcat) both already utilize JMX - the standard
> for managing Java applications and components.

First sentence in the spec: "The Java Management extensions (also called 
the JMX specification) define an architecture, the design patterns, the 
APIs, and the services for application and network /management and 
monitoring/ in the Java programming language."

There is big a difference between using JMX as it was intended for 
application and network /management and monitoring/ and using it as a 
component framework.

As David & Jules described, Jetty has its own component model and 
provides MBeans that bridge between it and JMX allowing Jetty components 
to be managed. The challenge with deep integrating Jetty into Geronimo 
was differences in the component model between Jetty (factory 
components) and Geronimo (IoC) rather than anything to do with JMX. The 
result that was a direct interface between Geronimo container and Jetty 
components, which allows those components to be exposed to management 
transparently /in a manner chosen by the container/ and hence 
independent from how the kernel is implemented.

The integration also allowed support for the separation between build- 
and run-time environments allowing pre-packaged deployment and reducing 
the runtime resource footprint.

I'm no expert on Tomcat internals but AIUI, Tomcat 5.x uses JMX as the 
basis of its component model with all components inheriting from JMX 
aware base classes and all inter-component interaction being sent 
through JMX. As a result, Tomcat is coupled to JMX not just for 
management but also as a core part of the component architecture. It is 
possible to run TC5 without JMX (IIRC at least one commercial 
organization has done that) but not easy.

I believe this hard coupling between component architecture 
implementation and management is flawed. Let me put it another way, I 
don't think anyone would seriously consider using SNMP for application 

> It seems to me that Geronimo needs to meet in the middle on this 
> issue. Requiring apps that have already implemented JMX to jump 
> through the hoops of a custom managment implementation does the 
> Geronimo community no good. I think that there should be a way to 
> bring apps like this into the Geronimo managment fold in an easy 
> manner or Geronimo needs to bridge the gap between a separation of
> the two.

There is nothing to stop a JMX instrumented application from being 
hosted in a Geronimo kernel, one that is JMX based or one that isn't. As 
demonstrated by the current Tomcat integration, you can host an 
application that uses JMX as a component framework in the same 
MBeanServer as a JMX-based Geronimo kernel and have common management 
through JMX.

As Jeff observed, the *DEBUG* console displays all MBeans be they 
Geronimo components or others; this is probably a bug as it would be 
more consistent if it only displayed Geronimo components. The *Geronimo 
Debug Console* only supports operations on Geronimo components as it is 
using the Geronimo kernel interface and not the underlying JMX 
implementation. But then its a debug tool not a management console.

Any true management tool has access via JMX to both Geronimo and 
non-Geronimo MBeans, allowing an admin to do as much damage as JMX 
security permits.

However, none of this really has anything to do with the original thread 
which is about integrating the Spring application component framework 
with the Geronimo system service component framework.


View raw message