geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Schumann <>
Subject Re: Why we must have JMX...
Date Tue, 12 Aug 2003 18:42:11 GMT
On 8/12/03 08:00 PM Jeremy Boynes <> wrote:

> Because it says so ... [J2EE1.4PFD3 pp 87] [JSR77 pp82]
> "the best tool for implementing the kernel ..."

.oO(is it just me who is already getting annoyed reading "the best" in every
second post? ;)
> Given that, we should support JMX for managing all components in the server.
> If an admin is using a JMX client, then they should be able to control the
> entire server not just the JSR77 mandated bits; they should be able to do
> everything through one UI. This means, regardless of the kernel
> architecture, all components should expose a JMX management interface.

Well, you should still differentiate between

A) administration and
B) operation.

Operations, the guys who usually maintain and observe the state of a system,
don't care about application internals. All they want to know is "Things are
up and running", or "down". Expressed by a green or red light in their
favorite SNMP tool. Correct me if I am wrong, but JMX support is still flaky
for HP OpenView, Tivoli etc. So you end up with an SNMP Adapter and MBeans
which expose standard types only (OpenMBeans) _including_ SNMP Trap support
(without management remains a toy).

On the other hand the administrator should be able to play with internals as
much as possible, the typical html console might be enough (however a
cluster view would be helpful).

> [... JBoss Micro Kernel ...]
> [... Avalon Micro Kernel ...]
> [... Homegrown JMX Kernel ...]

As I said in another thread:
Switching between JMX based and JMX enabled is painful, just ask the tomcat
guys. When I was looking the last time at the 5.0 CVS version you could see
the problems they were running into while moving towards a more or less JMX
based component architecture.

I would always vote for a home grown JMX Kernel from day no 1., which
provides the configuration mechanism, the component architecture, dependency
resolution, timer service and monitoring. But please don't try using it as
an invocation bus.

Just my 2 cents,


View raw message