[jbosscache-dev] JMX and MBeans in JBoss Cache 2.0.0

[Manik Surtani]

> jbosscache-dev-bounces at 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