Any more thoughts on this? Are we happy to provide:
1) A ServiceName attribute which binds a CacheMBean interface which allows
retrieval of configuration and statistics, as well as lifecycle operations, and
setters on some configs that may be changed at runtime
and
2) A JndiName attribute
Well, doing a printDetails() can be even longer. :-)
Pushing the config elements to various interceptor MBeans is a holy grail of
sorts, but is not feasible for all elements (some aren't attached to any
interceptor, others are used by 1 interceptor, etc).
Re: operations on the cache via the
1. You are right on printDetails(). So I guess if config element output is
formatted for human reading, a string output is fine as well.
2. If we will have mbean on the interceptor level, then I'd suggest to push as
much config attributes as possible since you are passing the config object in
re: 3) I'd still like to figure out how and why people use JMX to get a hold of
a cache instance.
I mean, maybe we should provide a JNDI binding for this sort of thing and only
provide a trimmed down JMX interface for statistics, configuration, lifecycle.
Basically, management, not operation.
Re: 2, print it as a String is fine for small space of parameters but it will
be difficult to read if we dump of all it as one. Is it possible to push the
config info to the individual interceptor mbean?
Finally, I do thing we need to support the operational method like put and get.
If we say
