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. Ralph -----Original Message----- From: Thor Heinrichs-Wolpert [mailto:[EMAIL PROTECTED] Sent: Saturday, March 27, 2004 8:35 AM To: [EMAIL PROTECTED] 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 negligible. Cheers, Thor HW
