geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Dynamic MBeans. Was: Kernel Architecture
Date Tue, 12 Aug 2003 16:10:32 GMT
Jens Schumann wrote:

>>Von: Berin Loritsch <>
>>Antworten an:
>>Datum: Tue, 12 Aug 2003 11:39:44 -0400
>>Betreff: Re: Dynamic MBeans. Was: Kernel Architecture
>>Jens Schumann wrote:
>>The thing is that there are certain compromises in the all-in-one box that
>>you have no control over.  Usually the manufacturers of these boxes can only
>>spend money on one part of it, and they skimp on the rest.  So it may have
>>a good tape player, but the CD player sucks (or vice versa).
> I agree with you. However I still don't get the point why relying on JMX is
> a critical factor, and usage of jakarta-commons* is considered harmful. JMX
> is a specification and it is up to you to implement it.

Umm, I don't recall saying anything about jakarta-commons*.  I use code from
there, and in general it is usually pretty good stuff.

>>>In the end it all boils down to whether a system is JMX enabled or JMX
>>>based. Interestingly most projects I have seen moved to JMX enabled at some
>>>stage, since too much stuff was maintained in parallel. However the
>>>transition from one to the other model is something you should avoid (just
>>>take a look at tomcat 5).
>>Seriously though, I would much prefer to have JMX enabled than JMX based,
>>as we can have more fine tuned control where we need it.  The JMX dynamic
>>classloading might be something causing problems instead of solving them.
>>If that happens, what is your recourse?
> See above, it is a specification. And I don't say JMX based is the only
> solution. But I believe most people here on the list talk about the
> instrumentation level only.

I understand that JMX is a specification.  The only major real damage that
I see here is one of the golden hammer.  The temptation with any new tool
is to go hog wild with it.  I am usually much more conservative, and introduce
the tool where I think it would help.  IOW, I start small.  Since JMX already
has a place where it lends a big help, I am resistent to endorsing a path where
it is the *only* solution.  As long as we can make it *one* solution out of
many, I will happily shut my trap.

Since you mentioned moving back and forth between JMX enabled and JMX
based is bad, that is yet another red flag that maybe we don't want to
go down that road.  But that is my conservative side talking.  I'm not
going to get in the way if you hell bent on going that direction.  I'm
just trying to find some balance here.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message