Berin suggested: > Anything that reduces the amount of coding that Avalon users have > to do the better.
Only if such facilities are provided in a modular enough manner so that they can be selected or removed easily, preferably without requiring source changes and a rebuild (eg. they would be configurable). Providing too many "mandatory" features hardwired into the kernel/container is not doing the users much of a service...it just makes more work for them when they have to unbolt the unwanted features. > The Phoenix approach builds JMX integration and generation into the > kernel/container layer. The exposed MBeans interact with the components > inside the container. That is definitely one way of doing it. I was still wondering what the pros/cons of doing this, versus making the JMX support a pluggable component would be? Anyone got any opinions? 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]>
