Ya, good point.
The example you mention does not consider recursion. If it has to be
"... consistent with the rule that a given type always implies the same
list of other key properties."
I guess we should use a schema like the following, where everything is
an UPnPDevice type
UPnP:type=UPnPDevice, UDN= "... id ....." , parentUDN= "even empty" ,
chidrenUDN="even empty"
UPnP:type=UPnPDevice.UPnPDevice, UDN= "... id ....." , parentUDN= "..."
, chidrenUDN="..."
UPnP:type=UPnPDevice.UPnPDevice.UPnPDevice, UDN= "... id ....." ,
parentUDN= "..." , chidrenUDN="..."
or distinguish between root and embedded devices
UPnP:type=UPnPDevice, UDN= "... id ....." , chidrenUDN="even empty"
UPnP:type=UPnPDevice.EmbeddeUPnPDevice, UDN= "... id ....." ,
parentUDN= "..." , chidrenUDN="..."
UPnP:type=UPnPDevice.EmbeddeUPnPDevice.EmbeddeUPnPDevice, UDN= "... id
....." , parentUDN= "..." , chidrenUDN="..."
(the used types could be also RootUPnPDevice and UPnPDevice for ones
embedded)
what do you prefer or what else you suggest?
Are such containment hierarchies automatically managed by the current
JMX consoles? just curious :-)
francesco
Didier Donsez wrote:
Francesco Furfari wrote:
Thanks Didier for the reference.
So far I tried a very simple approach and my types are basically
strings and hashtables.
I have just committed a directory trunk/upnp.doc you can use to
launch the configurations (same as mosgi, but you should check out
also upnp.jmxbridge and upnp.jmxbridge.tab on my sandbox).
The jmx bridge registers a ControlPoint MBean that notifies the
Remote UPnP console about new registered UPnPDeviceMBean on the
managed platform. The console then gets the XML description of the
device and display the RootDevice on the TreeViewer . The actions
execution is mapped on the "invokeAction" operation specifying the
serviceId of a service. Selecting a root device and clicking on the
Import button the UPnPDevice is registered on the platform.
What do you plan to do for sub-devices (ie embedded device such as IGD) ?
You could reuse the Object Name Conventions used by the JSR 77 (for
J2EE mbeans).
http://java.sun.com/products/JavaManagement/best-practices.html#mozTocId366979
gives some naming conventions for "hierarchical mbeans"
Didier
This approach for the moment is functional to console GUI i was
thinking to use, and I guess it is not very attractive for generic
JMX console. I have not idea if using generic console we can achieve
a good interaction model with remote devices. When a first stable
implementation will be ready we can discuss about it.
The code is still incomplete see commit logs for details.
francesco
Manuel Santillán wrote:
Well, Until recently I was not very fond of open mbeans, since they
are way to cumbersome to create. You had to handcraft the
serialization of data. It was really SNMP-ish. Recent support of
open mbeans in Java 6 simplifies it significantly, though...
Didier Donsez escribió:
Manuel Santillán wrote:
Hi Francesco,
Notifications in JMX can embed custom data if you like. Take a
look at the javax.management.Notification#setUserData(Object o)
and its related getter. One thing to take into account is that
you need to have knowledge of the type in the client. Hope it
helped!!
Hum, JMX best practices recommend to reuse open mbean types
So you can display your notified user data in off-the-shelves JMX
consoles (JConsole, ...)
You can have also a look on
http://java.sun.com/products/JavaManagement/best-practices.html#mozTocId199275
Didier
Cheers
//manuel
Manuel Santillán
Francesco Furfari escribió:
Dear Stephan , Manuel,
I need some hint about the notification mechanism in JMX.
I've figured out that mbean notifications allow to send only
simple messages.
If a client needs to receive complex data it has to pull the
data using, for example, the sequence number obtained in a
previous notification message.
Is this correct or I'm missing something?
thanks in advance
francesco
