cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject RE: [RT] On building on stone
Date Sat, 27 Mar 2004 22:07:38 GMT
Just to clarify this.  There are three types of MBeans; standard, dynamic,
and open. Only standard MBeans use reflection. Dynamic MBeans register their
methods, operations, etc.  OpenMBeans are dynamic MBeans but are restricted
to using OpenType objects (which are ArrayType, CompositeType, SimpleType,
or TabularType).  OpenMBeans allow complex objects to be returned to the GUI
without the GUI having to have knowledge of the "real" classes.  Since
OpenMBeans are dynamic MBeans they also do not use reflection but instead
register their methods, operations, etc.  

I would suggest that anytime anything that seems to be a runtime
"management" activity is to occur that the proper interface to use is JMX,
whether that is deploying an entire webapp, dynamically deploying a block,
changing pool or cache characterstics, etc.  Note that this does NOT require
that the container be implemented with JMX - only the interface to it.


-----Original Message-----
From: Thor Heinrichs-Wolpert [] 
Sent: Saturday, March 27, 2004 8:35 AM
Subject: Re: [RT] On building on stone

I think a big point (and that may be from never having used JMX) that 
is being missed.  When I was saying JMX and its style form part of a 
good kernel candidate, you have to look at how JMX is used.  It uses a 
standard reflection mechanism to talk to components.  Just to say it 
supports an MBean interface is missing quite a bit.  The main things it 
does it load, unload, start, stop and manage the config of components.  
It does this all by reflection, which isn't a big deal, other than the 
method calls are standardized.  There are some basic lifecycle states 
that can determine a components current state.

You can do reflection calls in many many styles.  It is sometimes nice 
to pick up and use one that is already well understood, and because of 
dynamic proxies can have extra behaviours added in.  You can't actually 
use JMX as a back plane for communication between components.  But you 
can follow the same style it uses throughout (consistency is sometimes 
a nice thing when there is no reason to alter it).

I'm not sure that there is an "other-side of the fence" where you don't 
need to make things work in real life if you are actually  a long-term 
living in this industry.  I'm going to assume that my JMX projects, 
others that are successful and the JBoss kernel argue the opposite of 
your "other side of the fence" comment.

These projects all focus on using standard interface, that any 
compatible, swappable component must implement.  They use reflection 
style calls to keep weak references between components so that the 
internal JVMs wont cache a method binding between components.  There is 
a small first time lag when the JVM has to get the lookup loaded for 
the reflection calls, but there are ways of speeding that up (by using 
something like BCEL) and after that the speed difference should be 

Thor HW

View raw message