Karl Pauls wrote:
Francesco, Stefano,
I spent the last hours coding the filter stuff. It works now and I
don't think there is anymore I can do. It needs cleaning-up (that's
for sure :-) and I will do that when I find some time but otherwise I
consider it done.
great
Some things to ponder:
First, I was right from the start. Your approach with the 1:1 mapping,
while nice and easy, is to nice, unfortunately. It will not work.
Apart from the code duplication (and believe me you would end-up with
a whole EventAdmin) section 113.7.2 of the spec calls it of. The point
is that asynchronous events must be delivered in the same order to all
EventHandlers. I cant see how this can be done with the proposed 1:1
mapping.
remind me to offer a beer next time you come in Italy ;-)
Second, I'm changing the filter of the UPnPEventListener on demand and
it turns out that the
org.apache.felix.upnp.sample.tv.UPnPEventListener doesn't handle
ServiceEvent.MODIFIED events. I guess this is a bug and needs to be
fixed in order for the bridge to work correctly with the example (and
anywhere else for that matter).
ya, the UPnP examples are still far to be considered best UPnP/Osgi
practice :(
I added the missing code to track service.MODIFIED events.
I tested your code and it works fine.
I used our examples as well as Intel devices , using both "NULL" filter
and ServiceId based.
I haven't checked all the possible combinations but looking at your code
it shouldn't be a problem.
What I've realized is that EA subscriptions are limited respect the
tracking possibilities offered by the UPnP spec.
Initially I suspected it was a bug in your code, using an handler with
the following filter:
"UPnP.service.type= urn:schemas-upnp-org:service:SwitchPower:1" the
light switches were not reported.
But this is consequence of the UPnP events type format in which only the
deviceId and serviceId are considered.
Hence the EA fails to match handlers with such filters.
So while in the UPnP spec the filters can be any combinations of
deviceId,deviceType,ServiceId and serviceType,
filters used with EventHandler can be only a combination of deviceId,
and serviceId.
Finally, keep in mind that it will still be the case that the
UPnPEventListener is registered with a null argument as soon as there
is any EventHandler that doesn't specify an
EventConstants.EVENT_FILTER. That would be needed regardless of any
approach. The only thing that can be done about it is to tell people
that this will lead to unnecessary network load that can be avoided if
they use a filter that targets the devices/services they are really
interested in.
well this is a user decision, in the old implementation it was an
imposition ;-)
thanks
francesco
