11:54 a.m.
On 3/4/13 10:59 AM, Jeff Mesnil wrote:
While working on adding AS7 notifications[1], I had an extensive look
at the JMX information model to see how it modelizes notifications.
I took the opportunity to make a comparison of the whole JMX information model (including
the extension for Model MBeans) to the AS7 resource model[2]
Notifications are the main thing missing in the AS7 resource model.
We have additional info (esp. a tree hierarchy) but there are some informations that JMX
provides and we do not.
Amon the interesting info that we are missing:
- deprecated => we have deprecated info for attribute and operation but not for the
resource as a whole
We should add this for AS 8.
- since => we have no information on when a
resource/attribute/operation has been added
I dread the effort to add this data for existing attributes. I also fear
it will end up being extremely inconsistently applied unless it can just
fall out of what we do for AS 9+ or be required at build time by the
code generation.
- displayName => we have no human-readable info suitable for
display (e.g. "JMS Queue" for jms-queue resource, same for attribute and
operation names)
This would have to have i18n applied. This seems like a good candidate
for inclusion when we determine the complete set of any additional
metadata we want to add to support UIs.
- lastUpdatedTimeStamp => when an attribute has been updated for
the last time
I don't think this is really applicable. We also don't have the notion
of 'value' -- the "Current (cached) value for attribute or operation" --
which is what this describes. A resource has a value, but the metadata
description does not.
One of the things in JMX I was never a fan of was some of the mixing of
'data' and 'metadata' that it has.
Additionally, JMX's ObjectName can define patterns. AS7
PathAddress allows only wildcard for the path element value (e.g.
/subsystem=messaging/hornetq-server=*/jms-queue=*) but not for a path element itself (e.g.
/subsystem=messaging/* to match child of the subystem).
The only use case where I would like to be able to use such a pattern is to register
notifications more simply (i.e., send me any notifications for the messaging subsystem is
simpler if I can use something like Ant's file pattern such as
/subsystem=messaging/**/* instead of having to iterate on all the resource in the tree).
If we allow that in PathAddress, we'll first have to validate that it
doesn't break other use cases for wildcards. The simple case is using a
wildcard to read attribute 'foo' on a bunch of resources. The child type
is *generally* what defines that 'foo' exists. If you try to read 'foo'
from other child types it's going to fail. And I'm not real inclined to
go to the effort to ignore those failures or figure out which resources
are truly applicable for the request. At least not in AS 8. :)
I said *generally* though. In quite a few cases the resources under
key=A and key=B have different definitions, and using a wildcard won't
work. So perhaps allowing a wilcard in the key wouldn't introduce any
fundamental difference. If a users uses a wildcard for something, they
need to understand the potential impact.
Some of these infos could be added to AS8 resource model.
If we find that these missing infos are interesting, we could add them to AS8 resource
model.
[1] https://issues.jboss.org/browse/AS7-370
[2]
https://docs.google.com/spreadsheet/ccc?key=0AgnxDyYwHtqVdE9RaW9IM2lZbzBo...
sorry for the color blind :)
[3] http://ant.apache.org/manual/dirtasks.html
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat