Re: [jboss-as7-dev] JMX [was: Dear subsystem owners/components leads ....]
On 8/19/11 10:35 AM, ssilvert(a)redhat.com wrote:
Quoting Scott Marlow<smarlow(a)redhat.com>:
> Heiko,
>
> Some of the JPA persistence providers support JMX for administrative
> operations (Hibernate statistics for example). Do we have any magic way
> to get JMX MBeans into the management console? Probably will need to be
> dynamic based on deployment time processing.
>
> Thanks,
> Scott
Scott,
Heiko is out for the rest of this month, so I'm not sure if he will be
able to answer.
Off hand, I don't think we currently have an easy way to directly
access JMX from the console. There would be a lot of low level
transport stuff to deal with that we've already worked through for the
management API. I doubt that we would want to go and build a
transport layer for JMX as well.
I think the better question is can we (should we) expose JMX through
the management API? If so it would be accessible from both the
console and the CLI.
Does anyone have thoughts about this?
We could only expose stuff that has an open mbean interface.
I don't like the idea of generally exposing everything that's in JMX via
the management API, e.g. with some resource tree
/jmx-domain=somedomain/some-objectname-key=some-objectname-value. The
problem is for that stuff the management layer would really just be a
thin wrapper over whatever unknown stuff a tech exposes in JMX, and that
unknown stuff would very likely include persistent configuration stuff.
Any use of that part of the management API would bypass the true
management layer.
Wherever possible we should focus on adding a proper domain management
layer for any tech we integrate that exposes whatever runtime stuff we
want from that tech's management interface but properly uses the domain
model for any persistent config.
Kabir's working on exposing the domain management layer via JMX. Those
mbeans will be in their own JMX domain. We'll clearly document that for
those using JMX, that JMX domain is the only safe one to use for any
persistent configuration.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat