On Tue, 08 Feb 2005 21:45:59 -0800, Jeremy Boynes wrote: > 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 > 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. My deepest apologies, Jeremy. I stand corrected. I'll be hung and quartered very shortly. Bruce -- perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E