Seems to me if someone wants to expose more operations via JMX it's a trivial exercise to subclass CacheJmxWrapper(MBean) and do it.
JBC should only support it directly if we agree that there's a good generally applicable use case for it that's compelling enough to trump the desire to not make CacheJmxWrapperMBean a control interface. Re: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098262#4098262, Hibernate exposes an API for evict data from the 2nd level cache. If there is no JMX interface to that API, that seems like something that should be dealt with by Hibernate. Encouraging users to bypass Hibernate and directly operate on JBC is analogous to someone exposing the JBC transaction table in JMX and letting users directly operate on it. Similar arguments apply to other AS usages of JBC. E.g. if I want to support a management layer that can remove a web session from the distributed web session cache, then that operation should be exposed by the web tier session manager. I don't want users directly going into the underlying cache and mucking around. Re: create/start/stop/destroy, you're right -- they don't fit. They are only there to support letting people deploy legacy -service.xml files in AS 5 by just changing the mbean's code attribute from org.jboss.cache.TreeCache to org.jboss.cache.jmx.CacheJmxWrapper. If we didn't want to support that (i.e. people have to use -beans.xml), we could remove the methods from the mbean interface. (Note I'm not advocating removing them at this late date; just discussing why they are there.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098387#4098387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098387 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
