hypfvieh / dbus-java

Improved version of java DBus library provided by freedesktop.org (https://dbus.freedesktop.org/doc/dbus-java/)
https://hypfvieh.github.io/dbus-java/
MIT License
185 stars 73 forks source link

Arbitrary signals with no interface #64

Closed rm5248 closed 5 years ago

rm5248 commented 5 years ago

With some of the previous arbitrary signals improvements, it's now possible to send and receive signals. This works fine for most use cases that I've encountered so far, but I've found a new use case where I'm only interested in listening to a signal with a type, member, and object(e.g. the AddMatch method to the DBus-daemon is type='signal',member='mymember','path=/'. In code, this is new DBusMatchRule( "signal", null, "mymember", "/")) This results in no callbacks being called, as the code for handling this assumes that there is always an interface.

I was considering adding a new block to the if statement(something like this:)

t = getGenericHandledSignals().get(new SignalTuple(null, _signal.getName(), _signal.getPath(), null));
if( null != t ) ...

However, this seems like it could easily get out of hand given the possible combinations of parts of the signal that could be null(4! = 24). Is there a better way to do this, or should I simply add some more statements to this block?

hypfvieh commented 5 years ago

I'm not so sure that it would be a good idea to allow 'null' as interface.

The reason why an interface is always expected is that the DBus spec says that signals must have an interface defined in the message header and one usually want to listen for a specific signal using a signal handler.

In case of the signal handlers, the code a bit further down will fail with NullPointerException.

Also the variable passed in to the handle() method of the interface will receive null... Maybe there are more places where values are not checked for 'null' I'm not aware of yet.

Anyway, I don't know any other method than adding more if-statements to that already long list of if-statements.

rm5248 commented 5 years ago

Since the interface can never be null when sending, there's no way we can have a NullPointerException. This basically just allows you to match * for the interface, e.g. you don't care what the interface is, but you may care about what the member name is.

PR #65 contains my proposed changes.

hypfvieh commented 5 years ago

I cleaned it a bit and merged your PR.