Berin responds: > The Phoenix container uses JMX to control specific components > that expose a JMX interface. There are two realities that need > to be controlled in CBD (Component Based Design): not all > components are controllers, and some components are too small > to be exposed like that. > > The components that are there to control a subsystem, or provide > interaction with an administrator, or administrating system (as > in your example), are candidates for the components that need > to be exposed by JMX. Some components only exist to do work under > the control of a master component. Those components really should > not be exposed to the administrator.
Of course, you should only expose components that need management exposure using JMX. You're preaching to the converted here, Berin. ;-) What I was hoping to get some opinions on was how JMX fits into the Avalon architecture....some "best practices" if you will. For example: Should JMX support be just another component (so you would have a JMX MBean Server component, JMX Agent components and of course, MBeans exposed by application components) that plugs into an Avalon Container? Or shoud some level of JMX support be "built-in" to the Container itself.....and maybe even into the Avalon Framework (as an "optional" module/interface of course)? Pros/Cons for these approaches? Not having had the time to look into the details of the Phoenix implementation, how is JMX included, from an architectural perspective, in Phoenix? Thx all! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
