> From: Andrzej Jan Taramina [mailto:[EMAIL PROTECTED]] > > 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.
JMX integration is _optional_. If the container does not support, or does not want to support JMX, then none of the MBeans have to be generated or used. That part of the component meta data is simply ignored. > > 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? In the future (Codename Spearhead AKA super/uber/etc Container) that will definitely be pluggable. Phoenix is has it automatically. I don't know about Merlin support, but Fortress does not currently support it. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
