jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Hi guys.
>
> Rather than wrestle with MBean interfaces and also add
> clutter to the various interfaces we have - and also to
> support future exposure of interceptors, etc. to JMX, what do
> you think of using Model MBeans instead of Standard MBeans?
>
>
http://java.sun.com/j2se/1.5.0/docs/api/javax/management/modelmbean/
> package-summary.html
That would be nice. Don't know if there will be any issue with the
properties that take a DOM Element.
>
> Now I'm no JMX expert and I may be talking nonsense here so
> feel free to tear this apart. Brian, how would something
> like this work for you since AS clustering gets cache
> references from JMX? Do we still need to extend ServiceMBean in AS5?
AS 5 services should be able to handle injection of pojos, so a cache
instance won't even need to be an MBean. I'll be dealing with the
cache
via the Cache interface. The cache should just expose create(),
start(), stop(), destroy(). Of course we want it to be an MBean for
management purposes, but it doesn't have to be to be used by things
like
session replication.
So is is just those 4 that we want to expose via JMX then? Ok, here
is what I propose we expose via JMX:
1) lifecycle, as mentioned above.
2) API to get a List<ObjectName> of bound interceptor MBeans (is this
necessary/useful?)
3) API to get Configuration
4) API to dump cache contents/printLockInfo()
5) API to get a hold of the Cache interface, and using this people
have direct access to the cache rather than directly exposing all of
the cache methods via JMX.
Thoughts?
Also, even for the 1.x series for integration in 4.0.x there's
no
requirement to extend ServiceMBeanSupport. Pretend for illustration we
wanted a 1.5.0. It would have to be a valid mbean and implement the 4
lifecycle methods, but implementing ServiceMBean or extending
ServiceMBeanSupport is not required.
Great. This means fewer jars in JBC as well. Bela will love this! :-)
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat