You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Francesco Furfari <fr...@isti.cnr.it> on 2006/09/14 14:00:53 UTC
JMX and UPnP
Hi JMX guys,
have you already implemented a bundle to publish UPnP devices with
jmood/mosgi?
I think it would be a nice project to add in Felix.
francesco
Re: JMX and UPnP
Posted by Manuel Santillan <sa...@dit.upm.es>.
> There would be also another interesting implementation for remote
> management, I don't know if JMX can come into help.
> I'm thinking a scenario where a Control Center installs a blinking
> light alarm, a physical UPnP device, on its local network and connects
> the Alarm device to some remote device of one or more managed gateways.
> There are also other interesting use cases ...
>
> Thus the path should be:
> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <-> Local
> UPnP Alarm
>
> Of corse we could choose other protocols in order to connect the two
> UPnP networks, but you are more experienced than me to tell if such
> chain is a convenient approach.
>
>
I'm no expert in UPnP, but wouldn't it be easier to bridge both devices
directly through the OSGi service registry?
Re: JMX and UPnP
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Well referring to the Manuel' message, unifying the implementations
would be a great move.
stephane.frenot@insa-lyon.fr wrote:
> Yes that's it.
> You can have two implementing ways :
>
> - UPnPdev <-> MBean <-> JMXConsole
> In this case each UPnP device declares an MBean which represent
> himself. So the JMXConsole can be considered as a controlPoint
>
I guess this approach is more general and so compatible also with Jmood,
isn't?
Here I need some hint on JMX architecture because I was wondering
whether a DynamicMbean is the right way for probing the UPnP devices.
Thinking to the data exchanged, my doubt are related to the mapping of
UPnP\Java data type. Would a generic JMX console be able to build
automatically the right interface to interact with the probed UPnP device?
>
> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
> In this case the control point declares a MBean that enable the
> JMXConsole to manage it.
>
> I have done the second one in a simple example.
Great, I'm curious to know how you have instrumented the Generic Control
Point :-). Do you have also implemented the GUI for the console?
Why not commit it in your sandbox ;-)
There would be also another interesting implementation for remote
management, I don't know if JMX can come into help.
I'm thinking a scenario where a Control Center installs a blinking light
alarm, a physical UPnP device, on its local network and connects the
Alarm device to some remote device of one or more managed gateways.
There are also other interesting use cases ...
Thus the path should be:
Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <-> Local
UPnP Alarm
Of corse we could choose other protocols in order to connect the two
UPnP networks, but you are more experienced than me to tell if such
chain is a convenient approach.
francesco
>
> /stephane
> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>> The question I don't understand is if you want to do some UPnP control
>>> point out of JMX ?
>>>
>>> /stephane
>> I'm not sure to understand your question. Are you asking if I want to
>> create a new GUI (Tab) for your console acting as a Generic Control
>> Point, that is similar to GUI of the bundle we have developed for
>> testing UPnP?
>> or the question is about bridging two local UPnP networks ?
>>
>> francesco
>>
>>
>
Re: JMX and UPnP
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Manuel Santillan wrote:
>
> Francesco Furfari escribió:
>> I re-send this message because I don't see it on the ML
>> ------------------------------------------------
>>
>>
>>
>> Well referring to the Manuel' message, unifying the implementations
>> would be a great move.
>>
>> stephane.frenot@insa-lyon.fr wrote:
>>> Yes that's it. You can have two implementing ways :
>>>
>>> - UPnPdev <-> MBean <-> JMXConsole
>>> In this case each UPnP device declares an MBean which represent
>>> himself. So the JMXConsole can be considered as a controlPoint
>>>
>> I guess this approach is more general and so compatible also with
>> Jmood, isn't?
>> Here I need some hint on JMX architecture because I was wondering
>> whether a DynamicMbean is the right way for probing the UPnP devices.
>> Thinking to the data exchanged, my doubt are related to the mapping of
>> UPnP\Java data type. Would a generic JMX console be able to build
>> automatically the right interface to interact with the probed UPnP
>> device?
> Generic consoles are only able to handle CompositeData (as well as
> java.lang.*, of course). When there is a complex data type, you can:
> 1. Just use it, but then the remote client has to know about it (and
> probably be designed to handle it)
> 2. Encapsulate it in a CompositeData, which is boring and error-prone
> 3. Register an MBean for that element. It is effectively equivalent to
> exporting it as a RMI remote object. It has lots of drawbacks, basically
> those of RMI: latency, network overuse and so on. On the client side,
> you can handle this issue by creating a "SnapshotProxy" (i.e, a local
> object that contains snapshot info on the remote object instead of
> accessing it directly)
>
> So as you see, there are not many options here. Usually, #3 is the most
> flexible. #2 is the most consistent with handling content.
> JMX's guys are dealing with this issues in Java 6. Basically they are
> creating a new type of MBean: MXBean (the same as
> java.lang.management.*MXBean) which automatically wraps and unwraps
> complex types in composite data. But, then again, Java 6's still in beta.
>
> Regarding DynamicMBeans, the StandardMBean class is in fact a
> DynamicMBean that exports the interface you pass to the constructor as
> the management interface. For many use cases is by far the simplest
> approach. Consider using DynamicMBeans if you need to add some
> transformations and you have to generate the management interface by
> introspection.
thanks for the useful clarification
francesco
>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>> In this case the control point declares a MBean that enable the
>>> JMXConsole to manage it.
>>> I have done the second one in a simple example.
>> Great, I'm curious to know how you have instrumented the Generic
>> Control Point :-) . Do you have also implemented the GUI for the console?
>> Why not commit it in your sandbox ;-)
>>
>> There would be also another interesting implementation for remote
>> management, I don't know if JMX can come into help.
>> I'm thinking a scenario where a Control Center installs a blinking
>> light alarm, a physical UPnP device, on its local network and connects
>> the Alarm device to some remote device of one or more managed gateways.
>> There are also other interesting use cases ...
>>
>> Thus the path should be:
>> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <-> Local
>> UPnP Alarm
>>
>> Of corse we could choose other protocols in order to connect the two
>> UPnP networks, but you are more experienced than me to tell if such
>> chain is a convenient approach.
>>
>> francesco
>>
>>
>>
>>> /stephane
>>> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>>>> The question I don't understand is if you want to do some UPnP
>> control
>>>>> point out of JMX ?
>>>>>
>>>>> /stephane
>>>> I'm not sure to understand your question. Are you asking if I want
>> to create a new GUI (Tab) for your console acting as a Generic Control
>> Point, that is similar to GUI of the bundle we have developed for
>> testing UPnP?
>>>> or the question is about bridging two local UPnP networks ?
>>>>
>>>> francesco
>>>>
>>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> stephane.frenot@insa-lyon.fr wrote:
>>> Yes that's it. You can have two implementing ways :
>>>
>>> - UPnPdev <-> MBean <-> JMXConsole
>>> In this case each UPnP device declares an MBean which represent
>>> himself. So the JMXConsole can be considered as a controlPoint
>>>
>>>
>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>> In this case the control point declares a MBean that enable the
>>> JMXConsole to manage it.
>>> I have done the second one in a simple example.
>>> /stephane
>>> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>>>> The question I don't understand is if you want to do some UPnP control
>>>>> point out of JMX ?
>>>>>
>>>>> /stephane
>>>> I'm not sure to understand your question. Are you asking if I want
>>>> to create a new GUI (Tab) for your console acting as a Generic
>>>> Control Point, that is similar to GUI of the bundle we have
>>>> developed for testing UPnP?
>>>> or the question is about bridging two local UPnP networks ?
>>>>
>>>> francesco
>>>>
>>>>
Re: JMX and UPnP
Posted by Manuel Santillan <sa...@dit.upm.es>.
Francesco Furfari escribió:
> I re-send this message because I don't see it on the ML
> ------------------------------------------------
>
>
>
> Well referring to the Manuel' message, unifying the implementations
> would be a great move.
>
> stephane.frenot@insa-lyon.fr wrote:
> > Yes that's it. You can have two implementing ways :
> >
> > - UPnPdev <-> MBean <-> JMXConsole
> > In this case each UPnP device declares an MBean which represent
> > himself. So the JMXConsole can be considered as a controlPoint
> >
>
> I guess this approach is more general and so compatible also with
> Jmood, isn't?
> Here I need some hint on JMX architecture because I was wondering
> whether a DynamicMbean is the right way for probing the UPnP devices.
> Thinking to the data exchanged, my doubt are related to the mapping of
> UPnP\Java data type. Would a generic JMX console be able to build
> automatically the right interface to interact with the probed UPnP
> device?
Generic consoles are only able to handle CompositeData (as well as
java.lang.*, of course). When there is a complex data type, you can:
1. Just use it, but then the remote client has to know about it (and
probably be designed to handle it)
2. Encapsulate it in a CompositeData, which is boring and error-prone
3. Register an MBean for that element. It is effectively equivalent to
exporting it as a RMI remote object. It has lots of drawbacks, basically
those of RMI: latency, network overuse and so on. On the client side,
you can handle this issue by creating a "SnapshotProxy" (i.e, a local
object that contains snapshot info on the remote object instead of
accessing it directly)
So as you see, there are not many options here. Usually, #3 is the most
flexible. #2 is the most consistent with handling content.
JMX's guys are dealing with this issues in Java 6. Basically they are
creating a new type of MBean: MXBean (the same as
java.lang.management.*MXBean) which automatically wraps and unwraps
complex types in composite data. But, then again, Java 6's still in beta.
Regarding DynamicMBeans, the StandardMBean class is in fact a
DynamicMBean that exports the interface you pass to the constructor as
the management interface. For many use cases is by far the simplest
approach. Consider using DynamicMBeans if you need to add some
transformations and you have to generate the management interface by
introspection.
>
> >
> > - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
> > In this case the control point declares a MBean that enable the
> > JMXConsole to manage it.
> > I have done the second one in a simple example.
>
> Great, I'm curious to know how you have instrumented the Generic
> Control Point :-) . Do you have also implemented the GUI for the console?
> Why not commit it in your sandbox ;-)
>
> There would be also another interesting implementation for remote
> management, I don't know if JMX can come into help.
> I'm thinking a scenario where a Control Center installs a blinking
> light alarm, a physical UPnP device, on its local network and connects
> the Alarm device to some remote device of one or more managed gateways.
> There are also other interesting use cases ...
>
> Thus the path should be:
> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <-> Local
> UPnP Alarm
>
> Of corse we could choose other protocols in order to connect the two
> UPnP networks, but you are more experienced than me to tell if such
> chain is a convenient approach.
>
> francesco
>
>
>
> >
> > /stephane
> > On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
> >>> The question I don't understand is if you want to do some UPnP
> control
> >>> point out of JMX ?
> >>>
> >>> /stephane
> >> I'm not sure to understand your question. Are you asking if I want
> to create a new GUI (Tab) for your console acting as a Generic Control
> Point, that is similar to GUI of the bundle we have developed for
> testing UPnP?
> >> or the question is about bridging two local UPnP networks ?
> >>
> >> francesco
> >>
> >>
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> stephane.frenot@insa-lyon.fr wrote:
>> Yes that's it. You can have two implementing ways :
>>
>> - UPnPdev <-> MBean <-> JMXConsole
>> In this case each UPnP device declares an MBean which represent
>> himself. So the JMXConsole can be considered as a controlPoint
>>
>>
>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>> In this case the control point declares a MBean that enable the
>> JMXConsole to manage it.
>> I have done the second one in a simple example.
>> /stephane
>> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>>> The question I don't understand is if you want to do some UPnP control
>>>> point out of JMX ?
>>>>
>>>> /stephane
>>> I'm not sure to understand your question. Are you asking if I want
>>> to create a new GUI (Tab) for your console acting as a Generic
>>> Control Point, that is similar to GUI of the bundle we have
>>> developed for testing UPnP?
>>> or the question is about bridging two local UPnP networks ?
>>>
>>> francesco
>>>
>>>
>>
Re: JMX and UPnP
Posted by Francesco Furfari <fr...@isti.cnr.it>.
santillan wrote:
> You're right. There is a SOAP connector being developed as a JSR. There is
> also an implementation in mx4j which provides a WSDL for the
> MBeanServerConnection class (superclass of MBeanServer). I had some problems
> with it last time. Anyway, as it provides an MBeanServer-like view, the
> other side has to be aware of JMX and the number of messages passed is high,
> so the only advantage I really do find useful is to go through firewalls
> that block RMI. But that's an opinion :-)
>
:-)
BTW using UPnP to monitor a control network is not so expensive, I mean
a typical network with sensors and actuators. Another discourse with
multimedia data.
francesco
> --
>
> Manuel Santillán <sa...@dit.upm.es>
> http://www.dit.upm.es/santillan
> Departamento de Ingeniería de Sistemas Telemáticos
> Escuela Técnica Superior de Ingenieros de Telecomunicación
> Universidad Politécnica de Madrid
> Avda. Complutense, s/n
> 28040 Madrid SPAIN
>
> Tel. +34 913367366 ext.3034
>
> -----Mensaje original-----
> De: Francesco Furfari [mailto:francesco.furfari@isti.cnr.it]
> Enviado el: viernes, 15 de septiembre de 2006 16:10
> Para: felix-dev@incubator.apache.org
> Asunto: Re: JMX and UPnP
>
>
>
> Manuel Santillan wrote:
>>> I understand, I was thinking to a different model where the device are
>>> instrumented on the fly. The UPnP philosophy is plug and use, in case
>>> of devices on the LAN, discovered by the Base Driver, and published on
>>> the framework you would break such tenet if you have to install a
>>> probe for it.
>> That's fairly easy on the agent side. If you've got both the upnp
>> object and the interface, you can just use the StandardMBean class. On
>> the other hand, if you have to introspect or read the metadata to create
>> the management interface, we could create a UPnPDynamicMBeanFactory that
>> handled those issues. It shouldn't be too hard, but DynamicMBeans,
>> although powerful, are a bit cumbersome, as you have to manually define
>> everything..
> Yes we have both, the problem I suspect, but give me the time to
> understand better JMX, could be the hierarchical structure of the UPnP
> device, the OSGi UPnP specification map the nested devices in a flat
> structure. I guess that a composed UPnP device would be divided in many
> "tabs" on the console. The user should look for the ParentUDN property
> of the device to understand how are logically assembled.
>>>>> Thinking to the data exchanged, my doubt are related to the mapping
>>>>> of UPnP\Java data type. Would a generic JMX console be able to build
>>>>> automatically the right interface to interact with the probed UPnP
>>>>> device?
>>>> Our jmxconsole is not generic, each gateway declares its own
>>>> management tab. It's not a generic/all discovery MBeans. You manage
>>>> the Beans you want, provided you have the corresponding tab in the
>>>> console. This is the main difference with generic consoles like MC4J
>>>> or JConsole. It is based on a very simple plugin mecanism like many
>>>> other...
>>>>
>>> So my doubts are founded. The Type of MBean I decide to use will
>>> influence the possibility of representation on a standard console.
>> Yep, but consider decoupling both sides. You can create your mbeans in a
>> way that can be handled by generic consoles: mc4j, jconsole, mishell,
>> etc, and then create a custom plugin/tab for stephane's jmxconsole. I
>> think it would be much more useful in this way, as many use cases
>> disallow having a Swing GUI.
> I've figured out that the plugin/tab for stephane' console is already
> deployed in a separate bundle, the only think needed in the Mbean is a
> description (identifier ?) of the plugin. Maybe this small information
> is compatible with you.
>
>>>>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>>>>> In this case the control point declares a MBean that enable the
>>>>>> JMXConsole to manage it.
>>>>>> I have done the second one in a simple example.
>>>>> Great, I'm curious to know how you have instrumented the Generic
>>>>> Control Point :-) . Do you have also implemented the GUI for the
>>>>> console?
>>>> As I told before, the console is aimed at device specific management
>>>> tasks. In my case it was a fridge management. So it's behaves like a
>>>> CP but for fridge devices. (Discovery, Sending requests...)
>>>>
>>>>> Why not commit it in your sandbox ;-)
>>>> Legal property issues...
>>>>
>>> :-(
>>>
>>>>> There would be also another interesting implementation for remote
>>>>> management, I don't know if JMX can come into help.
>>>>> I'm thinking a scenario where a Control Center installs a blinking
>>>>> light alarm, a physical UPnP device, on its local network and
>>>>> connects the Alarm device to some remote device of one or more
>>>>> managed gateways.
>>>>> There are also other interesting use cases ...
>>>>>
>>>>> Thus the path should be:
>>>>> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <->
>>>>> Local UPnP Alarm
>>>>>
>>>>> Of corse we could choose other protocols in order to connect the two
>>>>> UPnP networks, but you are more experienced than me to tell if such
>>>>> chain is a convenient approach.
>>>> Humm, your schema is a bit confusing. JMX is an agent, so it only
>>>> stores beans and provide a remote connectivity to them.
>>>>
>>>> JMXConsole <-> JMXConnector <-> JMX Agent <-> MBean <...>
>>>>
>>> Sorry I had condensed all the JMX layers in the JMX token
>>>
>>>> The communication between the console and the connector is remote and
>>>> is standardized with jmxremoting protocol. If I understand what you
>>>> want to do is to
>>>> substitue JMXConsole by a remote UPnPdev.
>>> I've not read the JMX console specification yet, so I was asking if
>>> the JMX specification can be used to abstract from the communication
>>> protocol used between the gateways.
>>> I was thinking to, let me say a "smart console", acting as the UPnP
>>> Base Driver. The console should register on the local framework a
>>> UPnPDevice service that is a proxy to the remote one. If there is also
>>> another UPnP Base driver on the same framework it would export the
>>> device to the local network of the Control center.
>>> So starting from the Control Center the chain should be:
>>> Control Center -- Remote Gateway
>>>
>>> Local UPnP Alarm <-> UPnP driver <-> UPnPDevice <-> "Smart Console"
>>> <-> JMXConnector <-> JMXAgent <-> MBean <-> UPnP-MbeanBridge <->
>>> UPnPDevice <-> Remote UPnP BaseDriver <-> remote UPnPdevice
>>>
>>> As said we could also adopt ad hoc protocols to bridge the two UPnP
>>> networks, I was asking if such approach is feasible for you, and
>>> convenient.
>>>
>> Yep, that approach is possible. However, in practice making it
>> protocol-agnostic through JMX in fact makes it JMX-over-RMI or
>> JMX-over-JRMP, as they seem to be the only connector implementations
>> readily available.
> :-)
>
> Nobody is working with soap?
>
RE: JMX and UPnP
Posted by santillan <sa...@dit.upm.es>.
You're right. There is a SOAP connector being developed as a JSR. There is
also an implementation in mx4j which provides a WSDL for the
MBeanServerConnection class (superclass of MBeanServer). I had some problems
with it last time. Anyway, as it provides an MBeanServer-like view, the
other side has to be aware of JMX and the number of messages passed is high,
so the only advantage I really do find useful is to go through firewalls
that block RMI. But that's an opinion :-)
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
-----Mensaje original-----
De: Francesco Furfari [mailto:francesco.furfari@isti.cnr.it]
Enviado el: viernes, 15 de septiembre de 2006 16:10
Para: felix-dev@incubator.apache.org
Asunto: Re: JMX and UPnP
Manuel Santillan wrote:
>> I understand, I was thinking to a different model where the device are
>> instrumented on the fly. The UPnP philosophy is plug and use, in case
>> of devices on the LAN, discovered by the Base Driver, and published on
>> the framework you would break such tenet if you have to install a
>> probe for it.
> That's fairly easy on the agent side. If you've got both the upnp
> object and the interface, you can just use the StandardMBean class. On
> the other hand, if you have to introspect or read the metadata to create
> the management interface, we could create a UPnPDynamicMBeanFactory that
> handled those issues. It shouldn't be too hard, but DynamicMBeans,
> although powerful, are a bit cumbersome, as you have to manually define
> everything..
Yes we have both, the problem I suspect, but give me the time to
understand better JMX, could be the hierarchical structure of the UPnP
device, the OSGi UPnP specification map the nested devices in a flat
structure. I guess that a composed UPnP device would be divided in many
"tabs" on the console. The user should look for the ParentUDN property
of the device to understand how are logically assembled.
>>
>>>> Thinking to the data exchanged, my doubt are related to the mapping
>>>> of UPnP\Java data type. Would a generic JMX console be able to build
>>>> automatically the right interface to interact with the probed UPnP
>>>> device?
>>> Our jmxconsole is not generic, each gateway declares its own
>>> management tab. It's not a generic/all discovery MBeans. You manage
>>> the Beans you want, provided you have the corresponding tab in the
>>> console. This is the main difference with generic consoles like MC4J
>>> or JConsole. It is based on a very simple plugin mecanism like many
>>> other...
>>>
>> So my doubts are founded. The Type of MBean I decide to use will
>> influence the possibility of representation on a standard console.
> Yep, but consider decoupling both sides. You can create your mbeans in a
> way that can be handled by generic consoles: mc4j, jconsole, mishell,
> etc, and then create a custom plugin/tab for stephane's jmxconsole. I
> think it would be much more useful in this way, as many use cases
> disallow having a Swing GUI.
I've figured out that the plugin/tab for stephane' console is already
deployed in a separate bundle, the only think needed in the Mbean is a
description (identifier ?) of the plugin. Maybe this small information
is compatible with you.
>>>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>>>> In this case the control point declares a MBean that enable the
>>>>> JMXConsole to manage it.
>>>>> I have done the second one in a simple example.
>>>> Great, I'm curious to know how you have instrumented the Generic
>>>> Control Point :-) . Do you have also implemented the GUI for the
>>>> console?
>>> As I told before, the console is aimed at device specific management
>>> tasks. In my case it was a fridge management. So it's behaves like a
>>> CP but for fridge devices. (Discovery, Sending requests...)
>>>
>>>> Why not commit it in your sandbox ;-)
>>> Legal property issues...
>>>
>> :-(
>>
>>>> There would be also another interesting implementation for remote
>>>> management, I don't know if JMX can come into help.
>>>> I'm thinking a scenario where a Control Center installs a blinking
>>>> light alarm, a physical UPnP device, on its local network and
>>>> connects the Alarm device to some remote device of one or more
>>>> managed gateways.
>>>> There are also other interesting use cases ...
>>>>
>>>> Thus the path should be:
>>>> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <->
>>>> Local UPnP Alarm
>>>>
>>>> Of corse we could choose other protocols in order to connect the two
>>>> UPnP networks, but you are more experienced than me to tell if such
>>>> chain is a convenient approach.
>>> Humm, your schema is a bit confusing. JMX is an agent, so it only
>>> stores beans and provide a remote connectivity to them.
>>>
>>> JMXConsole <-> JMXConnector <-> JMX Agent <-> MBean <...>
>>>
>> Sorry I had condensed all the JMX layers in the JMX token
>>
>>> The communication between the console and the connector is remote and
>>> is standardized with jmxremoting protocol. If I understand what you
>>> want to do is to
>>> substitue JMXConsole by a remote UPnPdev.
>> I've not read the JMX console specification yet, so I was asking if
>> the JMX specification can be used to abstract from the communication
>> protocol used between the gateways.
>> I was thinking to, let me say a "smart console", acting as the UPnP
>> Base Driver. The console should register on the local framework a
>> UPnPDevice service that is a proxy to the remote one. If there is also
>> another UPnP Base driver on the same framework it would export the
>> device to the local network of the Control center.
>> So starting from the Control Center the chain should be:
>> Control Center -- Remote Gateway
>>
>> Local UPnP Alarm <-> UPnP driver <-> UPnPDevice <-> "Smart Console"
>> <-> JMXConnector <-> JMXAgent <-> MBean <-> UPnP-MbeanBridge <->
>> UPnPDevice <-> Remote UPnP BaseDriver <-> remote UPnPdevice
>>
>> As said we could also adopt ad hoc protocols to bridge the two UPnP
>> networks, I was asking if such approach is feasible for you, and
>> convenient.
>>
> Yep, that approach is possible. However, in practice making it
> protocol-agnostic through JMX in fact makes it JMX-over-RMI or
> JMX-over-JRMP, as they seem to be the only connector implementations
> readily available.
:-)
Nobody is working with soap?
Re: JMX and UPnP
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Manuel Santillan wrote:
>> I understand, I was thinking to a different model where the device are
>> instrumented on the fly. The UPnP philosophy is plug and use, in case
>> of devices on the LAN, discovered by the Base Driver, and published on
>> the framework you would break such tenet if you have to install a
>> probe for it.
> That's fairly easy on the agent side. If you've got both the upnp
> object and the interface, you can just use the StandardMBean class. On
> the other hand, if you have to introspect or read the metadata to create
> the management interface, we could create a UPnPDynamicMBeanFactory that
> handled those issues. It shouldn't be too hard, but DynamicMBeans,
> although powerful, are a bit cumbersome, as you have to manually define
> everything..
Yes we have both, the problem I suspect, but give me the time to
understand better JMX, could be the hierarchical structure of the UPnP
device, the OSGi UPnP specification map the nested devices in a flat
structure. I guess that a composed UPnP device would be divided in many
"tabs" on the console. The user should look for the ParentUDN property
of the device to understand how are logically assembled.
>>
>>>> Thinking to the data exchanged, my doubt are related to the mapping
>>>> of UPnP\Java data type. Would a generic JMX console be able to build
>>>> automatically the right interface to interact with the probed UPnP
>>>> device?
>>> Our jmxconsole is not generic, each gateway declares its own
>>> management tab. It's not a generic/all discovery MBeans. You manage
>>> the Beans you want, provided you have the corresponding tab in the
>>> console. This is the main difference with generic consoles like MC4J
>>> or JConsole. It is based on a very simple plugin mecanism like many
>>> other...
>>>
>> So my doubts are founded. The Type of MBean I decide to use will
>> influence the possibility of representation on a standard console.
> Yep, but consider decoupling both sides. You can create your mbeans in a
> way that can be handled by generic consoles: mc4j, jconsole, mishell,
> etc, and then create a custom plugin/tab for stephane's jmxconsole. I
> think it would be much more useful in this way, as many use cases
> disallow having a Swing GUI.
I've figured out that the plugin/tab for stephane' console is already
deployed in a separate bundle, the only think needed in the Mbean is a
description (identifier ?) of the plugin. Maybe this small information
is compatible with you.
>>>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>>>> In this case the control point declares a MBean that enable the
>>>>> JMXConsole to manage it.
>>>>> I have done the second one in a simple example.
>>>> Great, I'm curious to know how you have instrumented the Generic
>>>> Control Point :-) . Do you have also implemented the GUI for the
>>>> console?
>>> As I told before, the console is aimed at device specific management
>>> tasks. In my case it was a fridge management. So it's behaves like a
>>> CP but for fridge devices. (Discovery, Sending requests...)
>>>
>>>> Why not commit it in your sandbox ;-)
>>> Legal property issues...
>>>
>> :-(
>>
>>>> There would be also another interesting implementation for remote
>>>> management, I don't know if JMX can come into help.
>>>> I'm thinking a scenario where a Control Center installs a blinking
>>>> light alarm, a physical UPnP device, on its local network and
>>>> connects the Alarm device to some remote device of one or more
>>>> managed gateways.
>>>> There are also other interesting use cases ...
>>>>
>>>> Thus the path should be:
>>>> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <->
>>>> Local UPnP Alarm
>>>>
>>>> Of corse we could choose other protocols in order to connect the two
>>>> UPnP networks, but you are more experienced than me to tell if such
>>>> chain is a convenient approach.
>>> Humm, your schema is a bit confusing. JMX is an agent, so it only
>>> stores beans and provide a remote connectivity to them.
>>>
>>> JMXConsole <-> JMXConnector <-> JMX Agent <-> MBean <...>
>>>
>> Sorry I had condensed all the JMX layers in the JMX token
>>
>>> The communication between the console and the connector is remote and
>>> is standardized with jmxremoting protocol. If I understand what you
>>> want to do is to
>>> substitue JMXConsole by a remote UPnPdev.
>> I've not read the JMX console specification yet, so I was asking if
>> the JMX specification can be used to abstract from the communication
>> protocol used between the gateways.
>> I was thinking to, let me say a "smart console", acting as the UPnP
>> Base Driver. The console should register on the local framework a
>> UPnPDevice service that is a proxy to the remote one. If there is also
>> another UPnP Base driver on the same framework it would export the
>> device to the local network of the Control center.
>> So starting from the Control Center the chain should be:
>> Control Center -- Remote Gateway
>>
>> Local UPnP Alarm <-> UPnP driver <-> UPnPDevice <-> "Smart Console"
>> <-> JMXConnector <-> JMXAgent <-> MBean <-> UPnP-MbeanBridge <->
>> UPnPDevice <-> Remote UPnP BaseDriver <-> remote UPnPdevice
>>
>> As said we could also adopt ad hoc protocols to bridge the two UPnP
>> networks, I was asking if such approach is feasible for you, and
>> convenient.
>>
> Yep, that approach is possible. However, in practice making it
> protocol-agnostic through JMX in fact makes it JMX-over-RMI or
> JMX-over-JRMP, as they seem to be the only connector implementations
> readily available.
:-)
Nobody is working with soap?
Re: JMX and UPnP
Posted by Manuel Santillan <sa...@dit.upm.es>.
> I understand, I was thinking to a different model where the device are
> instrumented on the fly. The UPnP philosophy is plug and use, in case
> of devices on the LAN, discovered by the Base Driver, and published on
> the framework you would break such tenet if you have to install a
> probe for it.
That's fairly easy on the agent side. If you've got both the upnp
object and the interface, you can just use the StandardMBean class. On
the other hand, if you have to introspect or read the metadata to create
the management interface, we could create a UPnPDynamicMBeanFactory that
handled those issues. It shouldn't be too hard, but DynamicMBeans,
although powerful, are a bit cumbersome, as you have to manually define
everything..
>
>
>>
>>> Thinking to the data exchanged, my doubt are related to the mapping
>>> of UPnP\Java data type. Would a generic JMX console be able to build
>>> automatically the right interface to interact with the probed UPnP
>>> device?
>> Our jmxconsole is not generic, each gateway declares its own
>> management tab. It's not a generic/all discovery MBeans. You manage
>> the Beans you want, provided you have the corresponding tab in the
>> console. This is the main difference with generic consoles like MC4J
>> or JConsole. It is based on a very simple plugin mecanism like many
>> other...
>>
> So my doubts are founded. The Type of MBean I decide to use will
> influence the possibility of representation on a standard console.
Yep, but consider decoupling both sides. You can create your mbeans in a
way that can be handled by generic consoles: mc4j, jconsole, mishell,
etc, and then create a custom plugin/tab for stephane's jmxconsole. I
think it would be much more useful in this way, as many use cases
disallow having a Swing GUI.
>
>>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>>> In this case the control point declares a MBean that enable the
>>>> JMXConsole to manage it.
>>>> I have done the second one in a simple example.
>>> Great, I'm curious to know how you have instrumented the Generic
>>> Control Point :-) . Do you have also implemented the GUI for the
>>> console?
>> As I told before, the console is aimed at device specific management
>> tasks. In my case it was a fridge management. So it's behaves like a
>> CP but for fridge devices. (Discovery, Sending requests...)
>>
>>> Why not commit it in your sandbox ;-)
>> Legal property issues...
>>
> :-(
>
>>> There would be also another interesting implementation for remote
>>> management, I don't know if JMX can come into help.
>>> I'm thinking a scenario where a Control Center installs a blinking
>>> light alarm, a physical UPnP device, on its local network and
>>> connects the Alarm device to some remote device of one or more
>>> managed gateways.
>>> There are also other interesting use cases ...
>>>
>>> Thus the path should be:
>>> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <->
>>> Local UPnP Alarm
>>>
>>> Of corse we could choose other protocols in order to connect the two
>>> UPnP networks, but you are more experienced than me to tell if such
>>> chain is a convenient approach.
>> Humm, your schema is a bit confusing. JMX is an agent, so it only
>> stores beans and provide a remote connectivity to them.
>>
>> JMXConsole <-> JMXConnector <-> JMX Agent <-> MBean <...>
>>
>
> Sorry I had condensed all the JMX layers in the JMX token
>
>> The communication between the console and the connector is remote and
>> is standardized with jmxremoting protocol. If I understand what you
>> want to do is to
>> substitue JMXConsole by a remote UPnPdev.
>
> I've not read the JMX console specification yet, so I was asking if
> the JMX specification can be used to abstract from the communication
> protocol used between the gateways.
> I was thinking to, let me say a "smart console", acting as the UPnP
> Base Driver. The console should register on the local framework a
> UPnPDevice service that is a proxy to the remote one. If there is also
> another UPnP Base driver on the same framework it would export the
> device to the local network of the Control center.
> So starting from the Control Center the chain should be:
> Control Center -- Remote Gateway
>
> Local UPnP Alarm <-> UPnP driver <-> UPnPDevice <-> "Smart Console"
> <-> JMXConnector <-> JMXAgent <-> MBean <-> UPnP-MbeanBridge <->
> UPnPDevice <-> Remote UPnP BaseDriver <-> remote UPnPdevice
>
> As said we could also adopt ad hoc protocols to bridge the two UPnP
> networks, I was asking if such approach is feasible for you, and
> convenient.
>
Yep, that approach is possible. However, in practice making it
protocol-agnostic through JMX in fact makes it JMX-over-RMI or
JMX-over-JRMP, as they seem to be the only connector implementations
readily available.
Re: JMX and UPnP
Posted by Francesco Furfari <fr...@isti.cnr.it>.
stephane.frenot@insa-lyon.fr wrote:
> On Fri, Sep 15, 2006 at 12:58:49PM +0200, Francesco Furfari wrote:
>> I re-send this message because I don't see it on the ML
>> ------------------------------------------------
>>
>>
>>
>> Well referring to the Manuel' message, unifying the implementations
>> would be a great move.
>>
>> stephane.frenot@insa-lyon.fr wrote:
>>> Yes that's it. You can have two implementing ways :
>>>
>>> - UPnPdev <-> MBean <-> JMXConsole
>>> In this case each UPnP device declares an MBean which represent
>>> himself. So the JMXConsole can be considered as a controlPoint
>>>
>> I guess this approach is more general and so compatible also with Jmood,
>> isn't?
>> Here I need some hint on JMX architecture because I was wondering
>> whether a DynamicMbean is the right way for probing the UPnP devices.
> Actually it depends on your business model. I am refering to a model
> where I know which devices I manage. So a device brings its
> own MBean and I don't need dynamicity. A bundles contains both the
> device and its management layers.
I understand, I was thinking to a different model where the device are
instrumented on the fly. The UPnP philosophy is plug and use, in case of
devices on the LAN, discovered by the Base Driver, and published on the
framework you would break such tenet if you have to install a probe for it.
>
>> Thinking to the data exchanged, my doubt are related to the mapping of
>> UPnP\Java data type. Would a generic JMX console be able to build
>> automatically the right interface to interact with the probed UPnP device?
> Our jmxconsole is not generic, each gateway declares its own
> management tab. It's not a generic/all discovery MBeans. You manage
> the Beans you want, provided you have the corresponding tab in the
> console. This is the main difference with generic consoles like MC4J
> or JConsole. It is based on a very simple plugin mecanism like many other...
>
So my doubts are founded. The Type of MBean I decide to use will
influence the possibility of representation on a standard console.
>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>> In this case the control point declares a MBean that enable the
>>> JMXConsole to manage it.
>>> I have done the second one in a simple example.
>> Great, I'm curious to know how you have instrumented the Generic Control
>> Point :-) . Do you have also implemented the GUI for the console?
> As I told before, the console is aimed at device specific management
> tasks. In my case it was a fridge management. So it's behaves like a
> CP but for fridge devices. (Discovery, Sending requests...)
>
>> Why not commit it in your sandbox ;-)
> Legal property issues...
>
:-(
>> There would be also another interesting implementation for remote
>> management, I don't know if JMX can come into help.
>> I'm thinking a scenario where a Control Center installs a blinking light
>> alarm, a physical UPnP device, on its local network and connects the
>> Alarm device to some remote device of one or more managed gateways.
>> There are also other interesting use cases ...
>>
>> Thus the path should be:
>> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <-> Local
>> UPnP Alarm
>>
>> Of corse we could choose other protocols in order to connect the two
>> UPnP networks, but you are more experienced than me to tell if such
>> chain is a convenient approach.
> Humm, your schema is a bit confusing. JMX is an agent, so it only
> stores beans and provide a remote connectivity to them.
>
> JMXConsole <-> JMXConnector <-> JMX Agent <-> MBean <...>
>
Sorry I had condensed all the JMX layers in the JMX token
> The communication between the console and the connector is remote and
> is standardized with jmxremoting protocol. If I understand what you want to do is to
> substitue JMXConsole by a remote UPnPdev.
I've not read the JMX console specification yet, so I was asking if the
JMX specification can be used to abstract from the communication
protocol used between the gateways.
I was thinking to, let me say a "smart console", acting as the UPnP Base
Driver. The console should register on the local framework a UPnPDevice
service that is a proxy to the remote one. If there is also another UPnP
Base driver on the same framework it would export the device to the
local network of the Control center.
So starting from the Control Center the chain should be:
Control Center -- Remote Gateway
Local UPnP Alarm <-> UPnP driver <-> UPnPDevice <-> "Smart Console" <->
JMXConnector <-> JMXAgent <-> MBean <-> UPnP-MbeanBridge <-> UPnPDevice
<-> Remote UPnP BaseDriver <-> remote UPnPdevice
As said we could also adopt ad hoc protocols to bridge the two UPnP
networks, I was asking if such approach is feasible for you, and
convenient.
francesco
> So you can have something like
>
> UPnP Control Point <-> UPnP Remote Device <- jmxremoting -> JMXConnector <...>
>
> I think there are no problems doing this.
>
> /stephane
>> francesco
>>
>>
>>
>>> /stephane
>>> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>>>> The question I don't understand is if you want to do some UPnP control
>>>>> point out of JMX ?
>>>>>
>>>>> /stephane
>>>> I'm not sure to understand your question. Are you asking if I want
>> to create a new GUI (Tab) for your console acting as a Generic Control
>> Point, that is similar to GUI of the bundle we have developed for
>> testing UPnP?
>>>> or the question is about bridging two local UPnP networks ?
>>>>
>>>> francesco
>>>>
>>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> stephane.frenot@insa-lyon.fr wrote:
>>> Yes that's it.
>>> You can have two implementing ways :
>>>
>>> - UPnPdev <-> MBean <-> JMXConsole
>>> In this case each UPnP device declares an MBean which represent
>>> himself. So the JMXConsole can be considered as a controlPoint
>>>
>>>
>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>> In this case the control point declares a MBean that enable the
>>> JMXConsole to manage it.
>>>
>>> I have done the second one in a simple example.
>>>
>>> /stephane
>>> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>>>> The question I don't understand is if you want to do some UPnP control
>>>>> point out of JMX ?
>>>>>
>>>>> /stephane
>>>> I'm not sure to understand your question. Are you asking if I want to
>>>> create a new GUI (Tab) for your console acting as a Generic Control
>>>> Point, that is similar to GUI of the bundle we have developed for
>>>> testing UPnP?
>>>> or the question is about bridging two local UPnP networks ?
>>>>
>>>> francesco
>>>>
>>>>
>
Re: JMX and UPnP
Posted by st...@insa-lyon.fr.
On Fri, Sep 15, 2006 at 12:58:49PM +0200, Francesco Furfari wrote:
> I re-send this message because I don't see it on the ML
> ------------------------------------------------
>
>
>
> Well referring to the Manuel' message, unifying the implementations
> would be a great move.
>
> stephane.frenot@insa-lyon.fr wrote:
> > Yes that's it. You can have two implementing ways :
> >
> > - UPnPdev <-> MBean <-> JMXConsole
> > In this case each UPnP device declares an MBean which represent
> > himself. So the JMXConsole can be considered as a controlPoint
> >
>
> I guess this approach is more general and so compatible also with Jmood,
> isn't?
> Here I need some hint on JMX architecture because I was wondering
> whether a DynamicMbean is the right way for probing the UPnP devices.
Actually it depends on your business model. I am refering to a model
where I know which devices I manage. So a device brings its
own MBean and I don't need dynamicity. A bundles contains both the
device and its management layers.
> Thinking to the data exchanged, my doubt are related to the mapping of
> UPnP\Java data type. Would a generic JMX console be able to build
> automatically the right interface to interact with the probed UPnP device?
Our jmxconsole is not generic, each gateway declares its own
management tab. It's not a generic/all discovery MBeans. You manage
the Beans you want, provided you have the corresponding tab in the
console. This is the main difference with generic consoles like MC4J
or JConsole. It is based on a very simple plugin mecanism like many other...
>
> >
> > - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
> > In this case the control point declares a MBean that enable the
> > JMXConsole to manage it.
> > I have done the second one in a simple example.
>
> Great, I'm curious to know how you have instrumented the Generic Control
> Point :-) . Do you have also implemented the GUI for the console?
As I told before, the console is aimed at device specific management
tasks. In my case it was a fridge management. So it's behaves like a
CP but for fridge devices. (Discovery, Sending requests...)
> Why not commit it in your sandbox ;-)
Legal property issues...
>
> There would be also another interesting implementation for remote
> management, I don't know if JMX can come into help.
> I'm thinking a scenario where a Control Center installs a blinking light
> alarm, a physical UPnP device, on its local network and connects the
> Alarm device to some remote device of one or more managed gateways.
> There are also other interesting use cases ...
>
> Thus the path should be:
> Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <-> Local
> UPnP Alarm
>
> Of corse we could choose other protocols in order to connect the two
> UPnP networks, but you are more experienced than me to tell if such
> chain is a convenient approach.
Humm, your schema is a bit confusing. JMX is an agent, so it only
stores beans and provide a remote connectivity to them.
JMXConsole <-> JMXConnector <-> JMX Agent <-> MBean <...>
The communication between the console and the connector is remote and
is standardized with jmxremoting protocol. If I understand what you want to do is to
substitue JMXConsole by a remote UPnPdev.
So you can have something like
UPnP Control Point <-> UPnP Remote Device <- jmxremoting -> JMXConnector <...>
I think there are no problems doing this.
/stephane
>
> francesco
>
>
>
> >
> > /stephane
> > On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
> >>> The question I don't understand is if you want to do some UPnP control
> >>> point out of JMX ?
> >>>
> >>> /stephane
> >> I'm not sure to understand your question. Are you asking if I want
> to create a new GUI (Tab) for your console acting as a Generic Control
> Point, that is similar to GUI of the bundle we have developed for
> testing UPnP?
> >> or the question is about bridging two local UPnP networks ?
> >>
> >> francesco
> >>
> >>
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> stephane.frenot@insa-lyon.fr wrote:
> >Yes that's it.
> >You can have two implementing ways :
> >
> >- UPnPdev <-> MBean <-> JMXConsole
> >In this case each UPnP device declares an MBean which represent
> >himself. So the JMXConsole can be considered as a controlPoint
> >
> >
> >- UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
> >In this case the control point declares a MBean that enable the
> >JMXConsole to manage it.
> >
> >I have done the second one in a simple example.
> >
> >/stephane
> >On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
> >>>The question I don't understand is if you want to do some UPnP control
> >>>point out of JMX ?
> >>>
> >>>/stephane
> >>I'm not sure to understand your question. Are you asking if I want to
> >>create a new GUI (Tab) for your console acting as a Generic Control
> >>Point, that is similar to GUI of the bundle we have developed for
> >>testing UPnP?
> >>or the question is about bridging two local UPnP networks ?
> >>
> >>francesco
> >>
> >>
> >
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: JMX and UPnP
Posted by Francesco Furfari <fr...@isti.cnr.it>.
I re-send this message because I don't see it on the ML
------------------------------------------------
Well referring to the Manuel' message, unifying the implementations
would be a great move.
stephane.frenot@insa-lyon.fr wrote:
> Yes that's it. You can have two implementing ways :
>
> - UPnPdev <-> MBean <-> JMXConsole
> In this case each UPnP device declares an MBean which represent
> himself. So the JMXConsole can be considered as a controlPoint
>
I guess this approach is more general and so compatible also with Jmood,
isn't?
Here I need some hint on JMX architecture because I was wondering
whether a DynamicMbean is the right way for probing the UPnP devices.
Thinking to the data exchanged, my doubt are related to the mapping of
UPnP\Java data type. Would a generic JMX console be able to build
automatically the right interface to interact with the probed UPnP device?
>
> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
> In this case the control point declares a MBean that enable the
> JMXConsole to manage it.
> I have done the second one in a simple example.
Great, I'm curious to know how you have instrumented the Generic Control
Point :-) . Do you have also implemented the GUI for the console?
Why not commit it in your sandbox ;-)
There would be also another interesting implementation for remote
management, I don't know if JMX can come into help.
I'm thinking a scenario where a Control Center installs a blinking light
alarm, a physical UPnP device, on its local network and connects the
Alarm device to some remote device of one or more managed gateways.
There are also other interesting use cases ...
Thus the path should be:
Remote UPnPdev <-> MBean <-> JMX <-> UPnPDev <-> UPnPDriver <-> Local
UPnP Alarm
Of corse we could choose other protocols in order to connect the two
UPnP networks, but you are more experienced than me to tell if such
chain is a convenient approach.
francesco
>
> /stephane
> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>> The question I don't understand is if you want to do some UPnP control
>>> point out of JMX ?
>>>
>>> /stephane
>> I'm not sure to understand your question. Are you asking if I want
to create a new GUI (Tab) for your console acting as a Generic Control
Point, that is similar to GUI of the bundle we have developed for
testing UPnP?
>> or the question is about bridging two local UPnP networks ?
>>
>> francesco
>>
>>
>
stephane.frenot@insa-lyon.fr wrote:
> Yes that's it.
> You can have two implementing ways :
>
> - UPnPdev <-> MBean <-> JMXConsole
> In this case each UPnP device declares an MBean which represent
> himself. So the JMXConsole can be considered as a controlPoint
>
>
> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
> In this case the control point declares a MBean that enable the
> JMXConsole to manage it.
>
> I have done the second one in a simple example.
>
> /stephane
> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>> The question I don't understand is if you want to do some UPnP control
>>> point out of JMX ?
>>>
>>> /stephane
>> I'm not sure to understand your question. Are you asking if I want to
>> create a new GUI (Tab) for your console acting as a Generic Control
>> Point, that is similar to GUI of the bundle we have developed for
>> testing UPnP?
>> or the question is about bridging two local UPnP networks ?
>>
>> francesco
>>
>>
>
Re: JMX and UPnP
Posted by Francesco Furfari <fr...@isti.cnr.it>.
santillan wrote:
> Yep,
> Adding mbeans is fairly easy. I am not very much aware of UPnP -yet :-)- but
> I understand that you do not know a priori which is the interface.
Well the UPnP Forum standardizes several types of UPnP Device so in
principle the interface is known a priori. But I was thinking to a
service that listens for every installed UPnP device and register
dynamilly a new MBean. For such reason I was thinking to adopt a dynamic
bean. But as written in the previous message I'm not sure it is the
right approach, I'm not very much aware of JMX too ;-)
francesco
If so,
> the simplest approach is to use the StandardMBean class:
> Class interface=//get your management interface class
> StandardMBean myMBean=new StandardMBean(impl, interface);
> ObjectName oname=ObjectName.getInstance("<This string should contain a valid
> objectname, in the form 'domain:key1=value1[, key2=value2...]'>");
> ManagementFactory.getPlatformMBeanServer.registerMBean(myBean, objectName);
>
> And when exiting,
> ManagementFactory.getPlatformMBeanServer.unRegisterMBean(objectName);
>
> --
>
> Manuel Santillán <sa...@dit.upm.es>
> http://www.dit.upm.es/santillan
> Departamento de Ingeniería de Sistemas Telemáticos
> Escuela Técnica Superior de Ingenieros de Telecomunicación
> Universidad Politécnica de Madrid
> Avda. Complutense, s/n
> 28040 Madrid SPAIN
> Tel. +34 913367366 ext.3034
>
> -----Mensaje original-----
> De: stephane.frenot@insa-lyon.fr [mailto:stephane.frenot@insa-lyon.fr]
> Enviado el: viernes, 15 de septiembre de 2006 10:12
> Para: felix-dev@incubator.apache.org
> Asunto: Re: JMX and UPnP
>
> Yes that's it.
> You can have two implementing ways :
>
> - UPnPdev <-> MBean <-> JMXConsole
> In this case each UPnP device declares an MBean which represent
> himself. So the JMXConsole can be considered as a controlPoint
>
>
> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
> In this case the control point declares a MBean that enable the
> JMXConsole to manage it.
>
> I have done the second one in a simple example.
>
> /stephane
> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>> The question I don't understand is if you want to do some UPnP control
>>> point out of JMX ?
>>>
>>> /stephane
>> I'm not sure to understand your question. Are you asking if I want to
>> create a new GUI (Tab) for your console acting as a Generic Control
>> Point, that is similar to GUI of the bundle we have developed for
>> testing UPnP?
>> or the question is about bridging two local UPnP networks ?
>>
>> francesco
>>
>>
>
Re: JMX and UPnP
Posted by Manuel Santillan <sa...@dit.upm.es>.
Didier Donsez escribió:
> Manuel Santillan wrote:
>
>> That's great news. Regarding Spoon, however, I've seen that Spoon is
>> CeCILL'ed (http://www.cecill.info/index.en.html ) and AFAIK is GPL-like.
>> Maybe there's an issue there
>>
>> BTW, have you committed some of your bundles to the sandbox?
>>
> I received my Apache account yesterday !
I was being to anxious, sorry :-)
>
>> I'm
>> especially interested in JmDNS at the moment,
> Sure, It enables to announce the JMX service urls
> We use it in JOnASonDemand to discover the instances of a J2EE cluster
> Mikael presented this at the OSGi World Congress 2005 in Paris.
>
> I have started to patch the JConsole (JDK 6.0) to add JMX service url
> discovery but this work is still under construction
> I can send you the code if you want to have a look on it !
That'd be great! In fact, mishell was inspired by an addition to
JConsole: the script interpreter that accepted Javascript. I started
playing around a bit and then things started to work. Having a look at
the code might help me solve a strange issue I have: I receive the event
but its ServiceInfo is null...
>
>> to let mishell discover
>> jmood, but it's LGPL'd, and I wanted to make some modifications
>>
>>
> I can change the licence but my code is only a SOA wrapper of the
> http://jmdns.sourceforge.net/
> And "
>
> The code (jmdns) is released under the LGPL license so that it can be
> freely incorporated into other products and services.
>
In fact, jmdns is also ASL'd so it works fine. I've looked at it and
played with the code, but I think it does not make sense to bundelize it
myself when you have done it already, so I'd rather use yours. In fact,
if you commited it, I could just handle the dependency with Maven..
> "
>
>> (basically removing the command, as I do not use OSGi shell in mishell
>> for obvious reasons)
>>
>> grrr, this licensing issues are boring... :-(
>>
>>
> Sure !
>
> Didier
>
>> Didier Donsez escribió:
>>
>>
>>> For info
>>>
>>> Clement and I plan to commit a JMX handler for iPOJO in the sandbox !
>>> The handler eases the MBean development !
>>>
>>> Another alternative is using Spoon JMX
>>> http://spoon.gforge.inria.fr/SpoonJMX/Main
>>> However it relies on the Java 5.0 annotations !
>>>
>>> santillan wrote:
>>>
>>>
>>>> Yep, Adding mbeans is fairly easy. I am not very much aware of UPnP
>>>> -yet :-)- but
>>>> I understand that you do not know a priori which is the interface. If
>>>> so,
>>>> the simplest approach is to use the StandardMBean class:
>>>> Class interface=//get your management interface class
>>>> StandardMBean myMBean=new StandardMBean(impl, interface);
>>>> ObjectName oname=ObjectName.getInstance("<This string should contain
>>>> a valid
>>>> objectname, in the form 'domain:key1=value1[, key2=value2...]'>");
>>>> ManagementFactory.getPlatformMBeanServer.registerMBean(myBean,
>>>> objectName);
>>>>
>>>>
>>>>
>>>>
>>> Moreover, MOSGi uses the whiteboard pattern to register/unregister
>>> MBeans
>>> You have just to register a OSGi service implementing a *MBean
>>> interface with a registration property "jmx.objectname" containing the
>>> objectName value.
>>> So you don't have to deal with ServiceListeners
>>> Stephane, can you confirm ?
>>>
>>> Didier
>>>
>>>
>>>> And when exiting,
>>>> ManagementFactory.getPlatformMBeanServer.unRegisterMBean(objectName);
>>>>
>>>> --
>>>>
>>>> Manuel Santillán <sa...@dit.upm.es>
>>>> http://www.dit.upm.es/santillan
>>>> Departamento de Ingeniería de Sistemas Telemáticos Escuela Técnica
>>>> Superior de Ingenieros de Telecomunicación Universidad Politécnica de
>>>> Madrid Avda. Complutense, s/n 28040 Madrid SPAIN Tel. +34 913367366
>>>> ext.3034
>>>>
>>>> -----Mensaje original-----
>>>> De: stephane.frenot@insa-lyon.fr
>>>> [mailto:stephane.frenot@insa-lyon.fr] Enviado el: viernes, 15 de
>>>> septiembre de 2006 10:12
>>>> Para: felix-dev@incubator.apache.org
>>>> Asunto: Re: JMX and UPnP
>>>>
>>>> Yes that's it. You can have two implementing ways :
>>>>
>>>> - UPnPdev <-> MBean <-> JMXConsole
>>>> In this case each UPnP device declares an MBean which represent
>>>> himself. So the JMXConsole can be considered as a controlPoint
>>>>
>>>>
>>>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>>> In this case the control point declares a MBean that enable the
>>>> JMXConsole to manage it.
>>>> I have done the second one in a simple example.
>>>> /stephane
>>>> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>>>
>>>>
>>>>
>>>>>> The question I don't understand is if you want to do some UPnP
>>>>>> control
>>>>>> point out of JMX ?
>>>>>>
>>>>>> /stephane
>>>>>>
>>>>> I'm not sure to understand your question. Are you asking if I want
>>>>> to create a new GUI (Tab) for your console acting as a Generic
>>>>> Control Point, that is similar to GUI of the bundle we have
>>>>> developed for testing UPnP?
>>>>> or the question is about bridging two local UPnP networks ?
>>>>>
>>>>> francesco
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>
>
Re: JMX and UPnP
Posted by Didier Donsez <di...@imag.fr>.
Manuel Santillan wrote:
>That's great news. Regarding Spoon, however, I've seen that Spoon is
>CeCILL'ed (http://www.cecill.info/index.en.html ) and AFAIK is GPL-like.
>Maybe there's an issue there
>
>BTW, have you committed some of your bundles to the sandbox?
>
I received my Apache account yesterday !
> I'm
>especially interested in JmDNS at the moment,
>
Sure, It enables to announce the JMX service urls
We use it in JOnASonDemand to discover the instances of a J2EE cluster
Mikael presented this at the OSGi World Congress 2005 in Paris.
I have started to patch the JConsole (JDK 6.0) to add JMX service url
discovery but this work is still under construction
I can send you the code if you want to have a look on it !
>to let mishell discover
>jmood, but it's LGPL'd, and I wanted to make some modifications
>
>
I can change the licence but my code is only a SOA wrapper of the
http://jmdns.sourceforge.net/
And "
The code (jmdns) is released under the LGPL license so that it can be
freely incorporated into other products and services.
"
>(basically removing the command, as I do not use OSGi shell in mishell
>for obvious reasons)
>
>grrr, this licensing issues are boring... :-(
>
>
Sure !
Didier
>Didier Donsez escribió:
>
>
>>For info
>>
>>Clement and I plan to commit a JMX handler for iPOJO in the sandbox !
>>The handler eases the MBean development !
>>
>>Another alternative is using Spoon JMX
>>http://spoon.gforge.inria.fr/SpoonJMX/Main
>>However it relies on the Java 5.0 annotations !
>>
>>santillan wrote:
>>
>>
>>
>>>Yep, Adding mbeans is fairly easy. I am not very much aware of UPnP
>>>-yet :-)- but
>>>I understand that you do not know a priori which is the interface. If
>>>so,
>>>the simplest approach is to use the StandardMBean class:
>>>Class interface=//get your management interface class
>>>StandardMBean myMBean=new StandardMBean(impl, interface);
>>>ObjectName oname=ObjectName.getInstance("<This string should contain
>>>a valid
>>>objectname, in the form 'domain:key1=value1[, key2=value2...]'>");
>>>ManagementFactory.getPlatformMBeanServer.registerMBean(myBean,
>>>objectName);
>>>
>>>
>>>
>>>
>>>
>>Moreover, MOSGi uses the whiteboard pattern to register/unregister MBeans
>>You have just to register a OSGi service implementing a *MBean
>>interface with a registration property "jmx.objectname" containing the
>>objectName value.
>>So you don't have to deal with ServiceListeners
>>Stephane, can you confirm ?
>>
>>Didier
>>
>>
>>
>>>And when exiting,
>>>ManagementFactory.getPlatformMBeanServer.unRegisterMBean(objectName);
>>>
>>>--
>>>
>>>Manuel Santillán <sa...@dit.upm.es>
>>>http://www.dit.upm.es/santillan
>>>Departamento de Ingeniería de Sistemas Telemáticos Escuela Técnica
>>>Superior de Ingenieros de Telecomunicación Universidad Politécnica de
>>>Madrid Avda. Complutense, s/n 28040 Madrid SPAIN Tel. +34 913367366
>>>ext.3034
>>>
>>>-----Mensaje original-----
>>>De: stephane.frenot@insa-lyon.fr
>>>[mailto:stephane.frenot@insa-lyon.fr] Enviado el: viernes, 15 de
>>>septiembre de 2006 10:12
>>>Para: felix-dev@incubator.apache.org
>>>Asunto: Re: JMX and UPnP
>>>
>>>Yes that's it. You can have two implementing ways :
>>>
>>>- UPnPdev <-> MBean <-> JMXConsole
>>>In this case each UPnP device declares an MBean which represent
>>>himself. So the JMXConsole can be considered as a controlPoint
>>>
>>>
>>>- UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>>>In this case the control point declares a MBean that enable the
>>>JMXConsole to manage it.
>>>I have done the second one in a simple example.
>>>/stephane
>>>On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>>
>>>
>>>
>>>
>>>>>The question I don't understand is if you want to do some UPnP control
>>>>>point out of JMX ?
>>>>>
>>>>>/stephane
>>>>>
>>>>>
>>>>>
>>>>I'm not sure to understand your question. Are you asking if I want
>>>>to create a new GUI (Tab) for your console acting as a Generic
>>>>Control Point, that is similar to GUI of the bundle we have
>>>>developed for testing UPnP?
>>>>or the question is about bridging two local UPnP networks ?
>>>>
>>>>francesco
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
--
--------------------------------------------------------------
Didier DONSEZ
INRIA/SARDES project, B117
655, avenue de l'Europe, Montbonnot
38334 St Ismier Cedex, France
Tel : +33 4 76 61 52 59 Fax : +33 4 76 61 52 52
GPS : lat 45°13'4.1"N, lon 05°48'24.3"E, alt 220m
Laboratoire LSR, Institut IMAG, Equipe ADELE
Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
mailto:Didier.Donsez@imag.fr
URL: http://www-adele.imag.fr/users/Didier.Donsez
Map: http://www-adele.imag.fr/users/Didier.Donsez/map/map.html
--------------------------------------------------------------
Re: JMX and UPnP
Posted by Manuel Santillan <sa...@dit.upm.es>.
That's great news. Regarding Spoon, however, I've seen that Spoon is
CeCILL'ed (http://www.cecill.info/index.en.html ) and AFAIK is GPL-like.
Maybe there's an issue there
BTW, have you committed some of your bundles to the sandbox? I'm
especially interested in JmDNS at the moment, to let mishell discover
jmood, but it's LGPL'd, and I wanted to make some modifications
(basically removing the command, as I do not use OSGi shell in mishell
for obvious reasons)
grrr, this licensing issues are boring... :-(
Didier Donsez escribió:
> For info
>
> Clement and I plan to commit a JMX handler for iPOJO in the sandbox !
> The handler eases the MBean development !
>
> Another alternative is using Spoon JMX
> http://spoon.gforge.inria.fr/SpoonJMX/Main
> However it relies on the Java 5.0 annotations !
>
> santillan wrote:
>
>> Yep, Adding mbeans is fairly easy. I am not very much aware of UPnP
>> -yet :-)- but
>> I understand that you do not know a priori which is the interface. If
>> so,
>> the simplest approach is to use the StandardMBean class:
>> Class interface=//get your management interface class
>> StandardMBean myMBean=new StandardMBean(impl, interface);
>> ObjectName oname=ObjectName.getInstance("<This string should contain
>> a valid
>> objectname, in the form 'domain:key1=value1[, key2=value2...]'>");
>> ManagementFactory.getPlatformMBeanServer.registerMBean(myBean,
>> objectName);
>>
>>
>>
> Moreover, MOSGi uses the whiteboard pattern to register/unregister MBeans
> You have just to register a OSGi service implementing a *MBean
> interface with a registration property "jmx.objectname" containing the
> objectName value.
> So you don't have to deal with ServiceListeners
> Stephane, can you confirm ?
>
> Didier
>
>> And when exiting,
>> ManagementFactory.getPlatformMBeanServer.unRegisterMBean(objectName);
>>
>> --
>>
>> Manuel Santillán <sa...@dit.upm.es>
>> http://www.dit.upm.es/santillan
>> Departamento de Ingeniería de Sistemas Telemáticos Escuela Técnica
>> Superior de Ingenieros de Telecomunicación Universidad Politécnica de
>> Madrid Avda. Complutense, s/n 28040 Madrid SPAIN Tel. +34 913367366
>> ext.3034
>>
>> -----Mensaje original-----
>> De: stephane.frenot@insa-lyon.fr
>> [mailto:stephane.frenot@insa-lyon.fr] Enviado el: viernes, 15 de
>> septiembre de 2006 10:12
>> Para: felix-dev@incubator.apache.org
>> Asunto: Re: JMX and UPnP
>>
>> Yes that's it. You can have two implementing ways :
>>
>> - UPnPdev <-> MBean <-> JMXConsole
>> In this case each UPnP device declares an MBean which represent
>> himself. So the JMXConsole can be considered as a controlPoint
>>
>>
>> - UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>> In this case the control point declares a MBean that enable the
>> JMXConsole to manage it.
>> I have done the second one in a simple example.
>> /stephane
>> On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>>
>>
>>>> The question I don't understand is if you want to do some UPnP control
>>>> point out of JMX ?
>>>>
>>>> /stephane
>>>>
>>> I'm not sure to understand your question. Are you asking if I want
>>> to create a new GUI (Tab) for your console acting as a Generic
>>> Control Point, that is similar to GUI of the bundle we have
>>> developed for testing UPnP?
>>> or the question is about bridging two local UPnP networks ?
>>>
>>> francesco
>>>
>>>
>>>
>>
>>
>>
>
>
Re: JMX and UPnP
Posted by st...@insa-lyon.fr.
On Fri, Sep 15, 2006 at 12:04:38PM +0200, Didier Donsez wrote:
> For info
>
> Clement and I plan to commit a JMX handler for iPOJO in the sandbox !
> The handler eases the MBean development !
>
> Another alternative is using Spoon JMX
> http://spoon.gforge.inria.fr/SpoonJMX/Main
> However it relies on the Java 5.0 annotations !
>
> santillan wrote:
>
> >Yep,
> >Adding mbeans is fairly easy. I am not very much aware of UPnP -yet :-)-
> >but
> >I understand that you do not know a priori which is the interface. If so,
> >the simplest approach is to use the StandardMBean class:
> >Class interface=//get your management interface class
> >StandardMBean myMBean=new StandardMBean(impl, interface);
> >ObjectName oname=ObjectName.getInstance("<This string should contain a
> >valid
> >objectname, in the form 'domain:key1=value1[, key2=value2...]'>");
> >ManagementFactory.getPlatformMBeanServer.registerMBean(myBean, objectName);
> >
> >
> >
> Moreover, MOSGi uses the whiteboard pattern to register/unregister MBeans
> You have just to register a OSGi service implementing a *MBean interface
> with a registration property "jmx.objectname" containing the objectName
> value.
> So you don't have to deal with ServiceListeners
> Stephane, can you confirm ?
Yes, that is it.
/stephane
>
> Didier
>
> >And when exiting,
> >ManagementFactory.getPlatformMBeanServer.unRegisterMBean(objectName);
> >
> >--
> >
> >Manuel Santillán <sa...@dit.upm.es>
> >http://www.dit.upm.es/santillan
> >Departamento de Ingeniería de Sistemas Telemáticos
> >Escuela Técnica Superior de Ingenieros de Telecomunicación
> >Universidad Politécnica de Madrid
> >Avda. Complutense, s/n
> >28040 Madrid SPAIN
> >Tel. +34 913367366 ext.3034
> >
> >-----Mensaje original-----
> >De: stephane.frenot@insa-lyon.fr [mailto:stephane.frenot@insa-lyon.fr]
> >Enviado el: viernes, 15 de septiembre de 2006 10:12
> >Para: felix-dev@incubator.apache.org
> >Asunto: Re: JMX and UPnP
> >
> >Yes that's it.
> >You can have two implementing ways :
> >
> >- UPnPdev <-> MBean <-> JMXConsole
> >In this case each UPnP device declares an MBean which represent
> >himself. So the JMXConsole can be considered as a controlPoint
> >
> >
> >- UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
> >In this case the control point declares a MBean that enable the
> >JMXConsole to manage it.
> >
> >I have done the second one in a simple example.
> >
> >/stephane
> >On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
> >
> >
> >>>The question I don't understand is if you want to do some UPnP control
> >>>point out of JMX ?
> >>>
> >>>/stephane
> >>>
> >>>
> >>I'm not sure to understand your question. Are you asking if I want to
> >>create a new GUI (Tab) for your console acting as a Generic Control
> >>Point, that is similar to GUI of the bundle we have developed for
> >>testing UPnP?
> >>or the question is about bridging two local UPnP networks ?
> >>
> >>francesco
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
> --
> --------------------------------------------------------------
> Didier DONSEZ
>
> INRIA/SARDES project, B117
> 655, avenue de l'Europe, Montbonnot
> 38334 St Ismier Cedex, France
> Tel : +33 4 76 61 52 59 Fax : +33 4 76 61 52 52
> GPS : lat 45°13'4.1"N, lon 05°48'24.3"E, alt 220m
>
> Laboratoire LSR, Institut IMAG, Equipe ADELE
> Universite Joseph Fourier
> Bat. C, 220 rue de la Chimie, Domaine Universitaire
> BP 53, 38041 Grenoble Cedex 9, France
> Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
> GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
>
> mailto:Didier.Donsez@imag.fr
> URL: http://www-adele.imag.fr/users/Didier.Donsez
> Map: http://www-adele.imag.fr/users/Didier.Donsez/map/map.html
> --------------------------------------------------------------
>
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: JMX and UPnP
Posted by Didier Donsez <di...@imag.fr>.
For info
Clement and I plan to commit a JMX handler for iPOJO in the sandbox !
The handler eases the MBean development !
Another alternative is using Spoon JMX
http://spoon.gforge.inria.fr/SpoonJMX/Main
However it relies on the Java 5.0 annotations !
santillan wrote:
>Yep,
>Adding mbeans is fairly easy. I am not very much aware of UPnP -yet :-)- but
>I understand that you do not know a priori which is the interface. If so,
>the simplest approach is to use the StandardMBean class:
>Class interface=//get your management interface class
>StandardMBean myMBean=new StandardMBean(impl, interface);
>ObjectName oname=ObjectName.getInstance("<This string should contain a valid
>objectname, in the form 'domain:key1=value1[, key2=value2...]'>");
>ManagementFactory.getPlatformMBeanServer.registerMBean(myBean, objectName);
>
>
>
Moreover, MOSGi uses the whiteboard pattern to register/unregister MBeans
You have just to register a OSGi service implementing a *MBean interface
with a registration property "jmx.objectname" containing the objectName
value.
So you don't have to deal with ServiceListeners
Stephane, can you confirm ?
Didier
>And when exiting,
>ManagementFactory.getPlatformMBeanServer.unRegisterMBean(objectName);
>
>--
>
>Manuel Santillán <sa...@dit.upm.es>
>http://www.dit.upm.es/santillan
>Departamento de Ingeniería de Sistemas Telemáticos
>Escuela Técnica Superior de Ingenieros de Telecomunicación
>Universidad Politécnica de Madrid
>Avda. Complutense, s/n
>28040 Madrid SPAIN
>Tel. +34 913367366 ext.3034
>
>-----Mensaje original-----
>De: stephane.frenot@insa-lyon.fr [mailto:stephane.frenot@insa-lyon.fr]
>Enviado el: viernes, 15 de septiembre de 2006 10:12
>Para: felix-dev@incubator.apache.org
>Asunto: Re: JMX and UPnP
>
>Yes that's it.
>You can have two implementing ways :
>
>- UPnPdev <-> MBean <-> JMXConsole
>In this case each UPnP device declares an MBean which represent
>himself. So the JMXConsole can be considered as a controlPoint
>
>
>- UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
>In this case the control point declares a MBean that enable the
>JMXConsole to manage it.
>
>I have done the second one in a simple example.
>
>/stephane
>On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>
>
>>>The question I don't understand is if you want to do some UPnP control
>>>point out of JMX ?
>>>
>>>/stephane
>>>
>>>
>>I'm not sure to understand your question. Are you asking if I want to
>>create a new GUI (Tab) for your console acting as a Generic Control
>>Point, that is similar to GUI of the bundle we have developed for
>>testing UPnP?
>>or the question is about bridging two local UPnP networks ?
>>
>>francesco
>>
>>
>>
>>
>
>
>
--
--------------------------------------------------------------
Didier DONSEZ
INRIA/SARDES project, B117
655, avenue de l'Europe, Montbonnot
38334 St Ismier Cedex, France
Tel : +33 4 76 61 52 59 Fax : +33 4 76 61 52 52
GPS : lat 45°13'4.1"N, lon 05°48'24.3"E, alt 220m
Laboratoire LSR, Institut IMAG, Equipe ADELE
Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
mailto:Didier.Donsez@imag.fr
URL: http://www-adele.imag.fr/users/Didier.Donsez
Map: http://www-adele.imag.fr/users/Didier.Donsez/map/map.html
--------------------------------------------------------------
RE: JMX and UPnP
Posted by santillan <sa...@dit.upm.es>.
Yep,
Adding mbeans is fairly easy. I am not very much aware of UPnP -yet :-)- but
I understand that you do not know a priori which is the interface. If so,
the simplest approach is to use the StandardMBean class:
Class interface=//get your management interface class
StandardMBean myMBean=new StandardMBean(impl, interface);
ObjectName oname=ObjectName.getInstance("<This string should contain a valid
objectname, in the form 'domain:key1=value1[, key2=value2...]'>");
ManagementFactory.getPlatformMBeanServer.registerMBean(myBean, objectName);
And when exiting,
ManagementFactory.getPlatformMBeanServer.unRegisterMBean(objectName);
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
-----Mensaje original-----
De: stephane.frenot@insa-lyon.fr [mailto:stephane.frenot@insa-lyon.fr]
Enviado el: viernes, 15 de septiembre de 2006 10:12
Para: felix-dev@incubator.apache.org
Asunto: Re: JMX and UPnP
Yes that's it.
You can have two implementing ways :
- UPnPdev <-> MBean <-> JMXConsole
In this case each UPnP device declares an MBean which represent
himself. So the JMXConsole can be considered as a controlPoint
- UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
In this case the control point declares a MBean that enable the
JMXConsole to manage it.
I have done the second one in a simple example.
/stephane
On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>
> >
> >The question I don't understand is if you want to do some UPnP control
> >point out of JMX ?
> >
> >/stephane
>
> I'm not sure to understand your question. Are you asking if I want to
> create a new GUI (Tab) for your console acting as a Generic Control
> Point, that is similar to GUI of the bundle we have developed for
> testing UPnP?
> or the question is about bridging two local UPnP networks ?
>
> francesco
>
>
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: JMX and UPnP
Posted by st...@insa-lyon.fr.
Yes that's it.
You can have two implementing ways :
- UPnPdev <-> MBean <-> JMXConsole
In this case each UPnP device declares an MBean which represent
himself. So the JMXConsole can be considered as a controlPoint
- UPnPdev <-> ControlPoint <-> MBean <-> JMXconsole
In this case the control point declares a MBean that enable the
JMXConsole to manage it.
I have done the second one in a simple example.
/stephane
On Fri, Sep 15, 2006 at 09:40:15AM +0200, Francesco Furfari wrote:
>
> >
> >The question I don't understand is if you want to do some UPnP control
> >point out of JMX ?
> >
> >/stephane
>
> I'm not sure to understand your question. Are you asking if I want to
> create a new GUI (Tab) for your console acting as a Generic Control
> Point, that is similar to GUI of the bundle we have developed for
> testing UPnP?
> or the question is about bridging two local UPnP networks ?
>
> francesco
>
>
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: JMX and UPnP
Posted by Francesco Furfari <fr...@isti.cnr.it>.
>
> The question I don't understand is if you want to do some UPnP control
> point out of JMX ?
>
> /stephane
I'm not sure to understand your question. Are you asking if I want to
create a new GUI (Tab) for your console acting as a Generic Control
Point, that is similar to GUI of the bundle we have developed for
testing UPnP?
or the question is about bridging two local UPnP networks ?
francesco
Re: JMX and UPnP
Posted by st...@insa-lyon.fr.
On Thu, Sep 14, 2006 at 05:49:55PM +0200, Manuel Santillan wrote:
> That's great news!
>
> BTW, I think that we can start alligning JMood and Mosgi contribs a little
> bit. I'm not willing to start a big refactoring effort just right now, and I
> suppose Stephane isn't either, so maybe we could start defining the common
> points so third parties can interwork with us. A couple of thoughts to start
> with:
> - Mosgi is using the PlatformMBeanServer, isn't it? I am, so as long as any
> bundle registers MBeans against that MBeanServer, it should work fine with
> both agents.
Not really, it is embedding also a leightweight MBean server. It's a
configuration parameter that uses either the platformMBeanServer or
the leightweighted.
The question I don't understand is if you want to do some UPnP control
point out of JMX ?
/stephane
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
RE: JMX and UPnP
Posted by Manuel Santillan <sa...@dit.upm.es>.
That's great news!
BTW, I think that we can start alligning JMood and Mosgi contribs a little
bit. I'm not willing to start a big refactoring effort just right now, and I
suppose Stephane isn't either, so maybe we could start defining the common
points so third parties can interwork with us. A couple of thoughts to start
with:
- Mosgi is using the PlatformMBeanServer, isn't it? I am, so as long as any
bundle registers MBeans against that MBeanServer, it should work fine with
both agents.
- We are both using RMI connectors, but we follow slightly different
approaches, I think dealing with that should not be too hard...
- We should establish an easy naming pattern for object names. This is easy
to overlook, but if well thought, writing queries for mbeans would become
simpler. I have no strong position on this point yet, so any ideas are
welcome.
Cheers!!!
//manuel
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
-----Mensaje original-----
De: stephane.frenot@insa-lyon.fr [mailto:stephane.frenot@insa-lyon.fr]
Enviado el: jueves, 14 de septiembre de 2006 16:18
Para: felix-dev@incubator.apache.org
Asunto: Re: JMX and UPnP
On Thu, Sep 14, 2006 at 03:21:49PM +0200, Francesco Furfari wrote:
> I would like to implement that, if you have not started yet.
> It is a way to get confidence with JMX for me.
> What do you think?
For me it is an excellent point.
/stephane
>
> francesco
>
>
> stephane.frenot@insa-lyon.fr wrote:
> >Not yet :)
> >
> >/stephane
> >On Thu, Sep 14, 2006 at 02:00:53PM +0200, Francesco Furfari wrote:
> >
> >>Hi JMX guys,
> >>have you already implemented a bundle to publish UPnP devices with
> >>jmood/mosgi?
> >>I think it would be a nice project to add in Felix.
> >>
> >>francesco
> >>
> >>
> >>
> >
> >
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: JMX and UPnP
Posted by st...@insa-lyon.fr.
On Thu, Sep 14, 2006 at 03:21:49PM +0200, Francesco Furfari wrote:
> I would like to implement that, if you have not started yet.
> It is a way to get confidence with JMX for me.
> What do you think?
For me it is an excellent point.
/stephane
>
> francesco
>
>
> stephane.frenot@insa-lyon.fr wrote:
> >Not yet :)
> >
> >/stephane
> >On Thu, Sep 14, 2006 at 02:00:53PM +0200, Francesco Furfari wrote:
> >
> >>Hi JMX guys,
> >>have you already implemented a bundle to publish UPnP devices with
> >>jmood/mosgi?
> >>I think it would be a nice project to add in Felix.
> >>
> >>francesco
> >>
> >>
> >>
> >
> >
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: JMX and UPnP
Posted by Francesco Furfari <fr...@isti.cnr.it>.
I would like to implement that, if you have not started yet.
It is a way to get confidence with JMX for me.
What do you think?
francesco
stephane.frenot@insa-lyon.fr wrote:
> Not yet :)
>
> /stephane
> On Thu, Sep 14, 2006 at 02:00:53PM +0200, Francesco Furfari wrote:
>
>> Hi JMX guys,
>> have you already implemented a bundle to publish UPnP devices with
>> jmood/mosgi?
>> I think it would be a nice project to add in Felix.
>>
>> francesco
>>
>>
>>
>
>
Re: JMX and UPnP
Posted by st...@insa-lyon.fr.
Not yet :)
/stephane
On Thu, Sep 14, 2006 at 02:00:53PM +0200, Francesco Furfari wrote:
> Hi JMX guys,
> have you already implemented a bundle to publish UPnP devices with
> jmood/mosgi?
> I think it would be a nice project to add in Felix.
>
> francesco
>
>
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------