geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: Why we must have JMX...
Date Tue, 12 Aug 2003 19:49:21 GMT

On Tuesday, Aug 12, 2003, at 19:42 Europe/London, Jens Schumann wrote:

> 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? ;)

Tell you what, let's go for the second best solution then :-)

>> 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.

And they both probably need different views of the application. 
Operations need things up/down (or attention when things are going 
wrong) whereas the administration/configuration probably needs a more 
detailed UI component to show all the information. How that's presented 
(web app, GUI whatever) probably doesn't depend on how it's found out 
(which may be JMX).

>> [... 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.

A Big Change Later would definately hurt. If we can use some of the 
ideas behind the Dynamic MBeans that were suggested earlier would give 
us the advantage in this respect.

> 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.

I really concur with the last point -- JMX should definately not be 
used as an invocation bus. And if we're going with a JMXAsKernel 
initially, this is one of the things that really could run into 
difficulties/performance issues later.

I'm also (personally) happy with the idea of JMX being used to 
interrogate components/services, but just not necessarily with ramming 
JMX down everything. For example, though JMX supports configuration 
(don't know how though), I feel that using JNDI, or JNDI over LDAP, 
will provide an excellent configuration mechanism, especially for 
distributed systems. My understanding of how JMX works in a distributed 
system for distributed config is a bit vague; I thought the config only 
worked per-JMX-MBean-server?


View raw message