-
1. 3759817
Ok., no confusion here about 1. and 2., but figured out the confusion.
For no 1.:
My basic design idea was to make a Model Mbean:
public class CacheService implements ModelMbean, MBeanRegistration, XMBeanConstants {
}
This does not use any ICache/CacheImpl interfacing/Extending.
Then in the MLet code pass an argument to the constructor which type of class the managed resource should be. In this case the Managed resource is a subclass of the Cache interface. Which operations to support can now dynamicaly be determined by reflecting the managed resource class type. And during the construction fase the ModelMBean can register a proxy in JNDI. But now we endup with a Model MBean, not a DynamicMBean. This ends up working exactly the other way around as you describe it ;-)!
Alternatively if CacheImpl is going to be managed as a DynamicMBean, then either the CacheImpl, or one of its superclasses (possibly interface ICache, no clue if that is compliant) has to implement the DynamicMBean interface.
Where I go amiss is:
org.jboss.cache.CacheImpl has got to be a MBean somehow either by implementing a DynamicMBean interface, either by being a ModelMBean.
For no 2.: This is where I managed to confuse you and myself. What I actually thought of doing was during task 1. register a dynamic proxy with JNDI, presetting it with a server reference so that when the proxy operates on the mbean, it doesn't have to lookup a server every time. But this is sort of sticky/dirty, and probably plainly wrong.
For the record: these are my first steps into JMX. I hope to contribute to the advancement of JCache, instead of stalling it.
