Wrong signal constructor retrieved #110
Comments
|
Without digging too much in your sample code, did you try to use the I would suggest you remove your 'AbstractInterface' Class and move the signal back to Then rename the signal so it is unique (e.g. closeWalletInt), add the |
|
Thanks for the suggestion. The dbus signature of the parameters ist still string for both signals. |
|
I think it is not possible to listen for both signals at the same time. Taking a look at DBusSignal.java, you will see that each signal is registered once in a map, where the key ist the name of the signal. If you add a second signal with the same name but different signature, it will overwrite the entry in the map. Therefore only one of the two signals will be handled. |
|
Just another quick note: So it may be suit your needs to listen to one of them. |
|
Thanks for elaborating on this. I agree. First, adding a SignalHandler for either one of the signals (so for the String one or for the int one) does work. I tested this yesterday. The respective signal can be handled then. You’ll have to decide on which signal you want to work with. This is sufficient for every kwallet application I can think of. Second, after your comment, I looked through the D-Bus specification and could not find anything that describes a requirement for the case described, hence to be able to listen for both signals at the same time. |
I have to correct myself, it did work with the test application, but not with my real world code. As you can see, I registered the signal in question once, as you advised above, but the one with the String signature gets also handled by the int-Signal with leads to an
The full TRACE is available on HiDrive. Edit: Updated link to source code. |
|
The problem is, that dbus-java identifies signals by it's name. When dbus-java tries to call the constructor of the signal using the received parameters, dbus-java does not check if the parameters received are compatible to the constructor. It just calls the constructor passing the received parameters. I guess this will not be easy to fix. I added a new branch ('ambigous-signals') which tries to handle that problem. I don't know if its working already ,I can't test it on my machine because kwallet does not work (don't know why). |
|
Thanks for looking into that so quickly! I tested my code with your new branch. The change swallows a couple of signals. Here is a comparison what happened in my code vs dbus-monitor: my code dbus-monitor during the same time: |
|
I updated the branch, could you please try again? |
|
Absolutely! Getting closer, but we are not yet there: The full TRACE is available on HiDrive. |
|
Another update on the branch. The issue was handling of primitives. While you will always get the wrapper version of primitives when gathering the class types of the received parameters, you will get the primitive version when asking the constructor for it's parameters if primitives were used in declaration. I tested it in a freshly installed kubuntu 20.04 virtual machine using the sample code you provided. Maybe you can have another look. |
I love to, as your fix is required for my code to work correctly. And I opened this issue, so testing from my side is required.
Great! I tested your change as well and receive all signals that get emitted now too and: registering both variants of the walletClosedInt The full TRACE on HiDrive. walletClosed The full TRACE on HiDrive. Thanks for the change to handle these ambiguous signals - I appreciate it very much! |
The changes introduced in #110 did not cover the use case of interfaces classes used as constructor arguments. When e.g. using Map or List interface in constructor the current expectedArgumentsList.equals(receivedArgumentsList) will fail, because the received arguments are not the interface type, but a compatible class. This requires some more attention, which means every expectedArgument has be be changed for compatibility to the received argument type. This behavior has been added in this commit. Every received argument is now checked with 'isAssignable' to the expected arguments. This will allow inheritance for objects as well as allowing the usage of interface classes in constructor definitions.
Hi,
thanks a lot for providing and maintaining dbus-java!
I implement a signal handler for the KWallet interface, that has two signals with the same name, but different contructors:
Reference: https://github.com/KDE/kwallet/blob/master/src/api/KWallet/org.kde.KWallet.xml
Demo code available at https://github.com/purejava/dbusjavatest.git - branch wip-kwallet-api -> simply run App.java.
Please note, that you need a KDE desktop environment or at least kwallet installed.
As Java does not allow to have two classes / signals of the same name, I introduced a second interface
AbstractInterface, that contains the second signal with theintsignature.On closing a wallet, both signals get emitted:
Nevertheless, the
instanceof-Code in the SignalHandler does identify both signals of the same type / instanceof KWallet, which is incorrect. One should be instanceof AbstractInterface.Looking through your code I could not find out what's wrong. Thanks.
The text was updated successfully, but these errors were encountered: