Francesco, you are right. The intention was to make a start - maybe I should have made that more clear.
but you are still registering an UPnPEventListener with a NULL filter thus *all* UPnP devices will start to send upnpEventNotify messages to the Bridge .... the same drawbacks for the network
That is not true in general, because now the UPnPEventListener is registered only in case at least one EventAdmin and at least on (applicable) EventHandler is present. Granted, once theses conditions are met, it is registered with a NULL filter.
You could also registering only an instance of UPnPEventListener but you should to update its filter every time a new EventHandler is registered or modified.
That was the ultimate goal. I'm still working on that part.
In any case you should always create a new UPnPeventListener if there are subscriber that want to receive events from all the devices ( they would register an handler with NULL filter).
Given the one UPnPEventListener with an ever updating "concatenated" filter why would I ever want to register a "new" UPnPEventListener. Isn't it sufficient to set the filter to null on the original one (whenever at least one EventHandler is interested on all events)?
Following up the previous discussion concerning postEvent or a direct call to the eventHandle, consider that the UPnP spec already states that the uppnpEventNotify messages must be sent asynchronously so should be enough safe (uhu aha :-) ) to call directly the eventHandle ...
Well, as I mentioned in my reply to Stefano, there is a bit more that it would need to do. Specifically, it would need to check that the EventHandler has the appropriate permissions to receive the event. Useful to know, however, that the UPnPEventListener is called asynchronously already.
ciao francesco
Give me a bit more time to give the "one UPnPEventListener with an ever updating concatenating filter" approach a shot. In case that won't fix it, I'm open to try different approaches. regards, Karl -- Karl Pauls [EMAIL PROTECTED]
