In Java SE 6 we made ObjectName wildcards more powerful, so it is now
possible to have a wildcard like
some.domain:type=Device,path="foo/bar/*". Therefore some of the
motivation for the previous recommendation goes away. Furthermore the
JConsole tool in the JDK does not currently recognize hierarchies that
follow the recommendation. The recommendation was basically a compromise
that attempted to build on the scheme that was implicitly followed in
JSR-77 for App Server management. I have no hesitation in suggesting
that people ignore it if it doesn't fit their needs. We should as you
suggest update the Best Practices guide to expand on this.
The suggestion of a parentMBean key is a good one and is more like what
we would have proposed if we hadn't had the prior art of JSR-77 to deal
with.
Éamonn McManus JMX Spec Lead http://weblogs.java.net/blog/emcmanus/
Francesco Furfari wrote:
Well just few words about UPnP ...
In the UPnP specification the containment hierarchy is used mainly
for discovering structured devices.
Starting to query the root device you get an XML description of all
embedded devices. The embedded devices follow the same functional
model of the root device.
Hence the recursive nature of their containment.
<device>
<its-ServiceList>
<device-list>
<device>
<its-ServiceList>
<device-list>
<device>
...
...
</device-list>
</device>
...
...
</device-list>
</device>
I'm trying to bridge UPnP devices between Osgi Platforms by means of
JMX. I'm also providing a dedicated GUI for a JMX console plugged on
the OSGi platform, thus so far it does not really matter how the
Mbeans are registered ... but as Didier has evenly pointed out in a
previous email we could use Object Name conventions ... I guess in
order to allow standard JMX console to properly present to the user
the containment hierarchy.
Well nothing to add to your comments about the problems with recursive
containment. What I can propose is to add\define a convention to
address such issue. Also in the OSGi specification the upnp devices
are flattened as services of the same type, and links to the parent
and to the device's children are saved as property keys.
A similar convention could be used in JMX.
As far as I've understood the current convention easies the grouping
of Mbeans. If you want to know which objects are contained in the
type=A.B, you have just to query for object with the keys A and B
having a specific value. Even if it seems to me that in this way you
are not able to limit the target of your query to just a single level
of containment.
Perhaps adding a standard key like parentMBean could help ...
I believe it should be appropriate also for our needs.
best regards
francesco
Didier Donsez wrote:
About the UPnP JMX ObjectName naming convention, the answer of the
expert ;-)
Didier
"
Didier,
There isn't really enough context for me to suggest something. The
containment convention suggested in the Best Practices guide does
have a problem with recursive containment. The idea is that if you
have type=A.B.C then you must also have keys A=something and
B=something. This means that A and B can't be the same. If the UDN is
enough to determine the parent then it's probably not worth trying to
include the parent explicitly in other ObjectName keys.
Feel free to forward this message and/or include me in the discussion.
Regards,
Éamonn McManus JMX Spec Lead http://weblogs.java.net/blog/emcmanus/
"
