You might want to ping Scott/Adrian to see how this ties in with what they are doing. They have a concept of a ManagedObject that's meant to describe this kind of thing. I'm sure tools like JBoss ON are going to want a consistent API for discovering what features are runtime changeable.
The api is associated with the profile service and is rooted at the org.jboss.deployers.spi.management.ManagementView. There is simple org.jboss.deployers.spi.management.ManagedObject representation of a bean's management interface. How the ManagedObject is obtained for a component is a function of the deployer associated with the component. So far we have not gotten to how the deployers extract the ManagedObject from a deployment metadata. We'll have to define annotations and schemas for this.
Adrian did create a org.jboss.mx.mxbean.MXBean prototype that illustrates some concepts of the jdk6 MXBean:
This just seems like a mechanism of how I would expose setters to allow mutation of certain configs via JMX or the profile service.
The purpose of this thread is more to talk about *how* I plan to enforce such mutability internally (since programmatically someone can still get a hold of the Configuration object and change it), as well as a discussion on which elements should be mutable.
Yes, that is correct. You have to define your management interface and then expose it so that the managment layer understands it.
Manik, should useInterceptorMBean be runtime configurable as well just for the management purpose? Most of the time, I may want to turn it off for performance but use it for periodic monitoring.
I'm ok with this being a RT variable, but then it should not be injected into the inteceptors when the chain is configured, but should be referenced directly from the Configuration.
You also suggested changing isUseInterceptorMBean to isUseMBean. +1 to both, are you going to make the change together?