Also, at the moment this is only tried out in standalone servers.
When running in a domain, I suspect we would want to expose the DC's model in jmx and
hide the individual servers?
Would exposing the servers (and remote HCs from the DC) be significantly
harder?
On 22 Aug 2011, at 17:50, Kabir Khan wrote:
> The ongoing work for the JMX facade to the management model lives here:
https://github.com/kabir/jboss-as/commits/jmx-facade
>
> I'm still working through a few things before this is complete. I've included
a description of how this works, along with some assumptions, things I came across when
doing this and some questions.
>
> To set up the management mbean stuff, I have added an optional element called
'show-model' to the jmx subsystem:
> <subsystem xmlns="urn:jboss:domain:jmx:1.0"
show-model="true">
> <jmx-connector registry-binding="jmx-connector-registry"
server-binding="jmx-connector-server" />
> </subsystem>
> The default value is 'false', do I need to bump up the schema version number
in this case (it is backwards compatible). If 'true' I wrap the mbean server in a
similar way to TcclMBeanServer and look at the management model, i.e. no mbeans are
actually created.
>
> In brief how it works is that every resource in the model has an associated MBean in
the 'jboss.model' domain , so for example '/subsystem=jmx' becomes
'jboss.model:subsystem=jmx'. All MBeans are described using OpenMBeanInfo.
> The resource attributes become attributes on that mbean, and operations become
operations on that mbean. An exception to the operations are the standard 'add'
operations, so if you want to invoke '/subsystem=foo/child=blah:add()', the
'add' method lives on the parent MBean instead, so you would invoke the
'add-child' operation on 'jboss.model:subsystem=foo'.
>
> The root of the model is registered under 'jboss.model:type=root'.
>
> The types of attributes and operation parameters are defined using the open mbean
types. For simple attributes where 'type=INT', that becomes an open mbean
SimpleType.INT and so on. More Complex types are also handled, for example;
> * {type=>LIST,value-type=>STRING} becomes a String[] (i.e. an ArrayType where
the element type is SimpleType.STRING)
> * {type=>OBJECT,value-type=>LONG} becomes a map represented by TabularType,
where the index is called 'key' and each entry is a CompositeData containing the
key under 'key' and the value under 'value'.
> * Complex objects, such as
{type=>OBJECT,value-type=>{{one=>{type=STRING},{two=>{type=INT}}} become a
CompositeData where 'one' has the type SimpleType.STRING and 'two' has the
type
SImpleType.INT.
>
> I still have to handle ModelType.PROPERTY, I left that until the end - I think this
will become a CompositeData. I still need to look where PROPERTY is used in the model and
see if we need to force those to have a VALUE_TYPE or if String can be assumed.
>
> I am not inheriting any of the global operations at the moment (read-attribute,
read-resource-description etc.), and am not sure if it makes to include them even in
'jboss.model:type=root' since they are detyped model specific, most of the
information from these ops is available in other ways via jmx. I still need to verify that
all mbeans can be described in AS, but I've already seen that these global ops need
some work to get them to work since the root mbean fails on those.
>
> I am not doing anything to handle operations that have more than one
REPLY_PROPERTIES, I guess if they do I should roll them into a CompositeData?
>
> I noticed one thing when using jconsole. If you attach to a 'local' process
we never hit my management model wrapper or TcclMBeanServer, that only happens if you
connect to localhost:1090 so it comes in via the connector. I need to look at this part of
the spec but maybe an MBeanServerDelegate/MBeanServerFactory or something could be used so
that the behaviour always is available.
>
> I am not allowing notification listeners to be registered under
'jboss.model:'. It might be possible to add another configuration persister to
trap these events, but since (I think) we only really know if the model has changed or
not, not what has actually changed, I think that would add overhead at the moment until
notifications are added to the core management model.
>
> I am not handling the query parameter to queryMBeans(ObjectName name, QueryExp query)
or queryNames(ObjectName name, QueryExp query) in the wrapper, only the query parameter.
>
> Due to jmx using 'proper' method signatures where the order of the operation
parameters is important, and the detyped management model using request-properties keyed
by name, if the management model changes the order of parameters between releases jmx
clients will break.
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev