> From: Andrzej Jan Taramina [mailto:[EMAIL PROTECTED]] > > 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)?
The Phoenix approach builds JMX integration and generation into the kernel/container layer. The exposed MBeans interact with the components inside the container. I think that is a reasonable way of doing it. If you don't want a container that performs those functions, then that facility is removed from the system easily. > Pros/Cons for these approaches? Anything that reduces the amount of coding that Avalon users have to do the better. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
