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/
"