??? 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 architecture.
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.
-- Jeremy
