I will be looking into this once more. There are two issues I'm aware of: - lack of configuration options - bugs in the org.apache.jmx stuff caused because MBeans do not support equals() There's also the issue of which pattern to use for registering and deregistering Components which also are MBeans. I'd like to have some discussion on this... 1) should there be a MBeanComponent interface that extends Component and MBean? This means a little less typing. What I do not like is that when a Component is an MBean it is also a JavaBean by definition. I want our (JMX-like) management to work with non-JavaBean-Components as well. To make this conceptually clear, we'd have to have a ManagedComponent which would be manageable by our management system but not by an MBeanServer. Ugly. Another option would be to have a MBeanFromComponentFactory that provides a MBean getMBeanFromComponent(Component); which takes the get()/set() and lifecycle methods of the Component and puts them in an MBean...... 2) where is the responsibility for determining whether a Component is manageable and whether it _should_ be managed? The answer to second question is of course either a Manageable or an MBean interface. The second question is more difficult. I'm leaning towards defining this in one of the .xml config files (or the config file once they're merged -- was that voted yes or no?). 3) where should Components be registered and deregistered? I'd say this is something to do in the Container. But from where on in the lifecycle do you expose a Component as an MBean, and from whereon shouldn't you? (this also determines which lifecycle methods the Component should _not_ expose through its MBean). 4) where do we put the MBeanServer? Options are RMIRegistry (current), but the new JNDI framework Cadastre is also an option (though that would probably delay phoenix release)? Also, should LDAP be an option? If we make this configurable, where should this be configured? phoenix.xml? How? guess that's enough to think about for now, right? cheers, Leo, A Busy Guy(tm) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
