geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <>
Subject Re: Using JMX, was: Spring integration...
Date Wed, 09 Feb 2005 07:56:42 GMT
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.

perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
The Castor Project

Apache Geronimo

View raw message