Jens Schumann wrote:
MBean != interface, and we should never use them as such. By following that
mantra, dynamic MBeans becomes a viable tool with few drawbacks.
Well, this is true if you talk about the instrumentation level only. But if
you trust in JMX agents for application management you are moving towards
the MBean == interface analogy. In my opinion JMX offers a lot more than
management, stuff you need to implement anyway: Dynamic Classloading,
Notifications, Monitoring, Relations and Lifecycle of components.
My alarm bells go off every time I hear that an object should ever be
considered
synonymous with a simple interface.
All of those other aspects: dynamic classloading, notifications, monitoring,
etc. can be addressed by other means--many times more effectively.
I get nervous when I here something slices, dices, makes julian fries, and
will not break (oops! it broke). That combination hooka and coffie maker
(get the movie reference now?) might better be served with different mechanisms.
For example, in the world of audio and home entertainment systems, you have
two camps:
1) The all in one jobbies--usually less expensive
2) Component systems--usually more expensive
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).
With the component systems, you can get exactly what you want for the job
at hand. If you don't want a tape player, you don't have to buy one. If
you really care about your CD player, you can spend money on a good one.
In other words, if something isn't up to snuff you have the ability to swap
it out at any time for a better component. You aren't stuck with what the
initial manufacturer decided was best for you.
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).
<shudder/>
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?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
