Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interface name mapping disappeared #186

Closed
gsavin opened this issue Sep 8, 2022 · 9 comments
Closed

Interface name mapping disappeared #186

gsavin opened this issue Sep 8, 2022 · 9 comments

Comments

@gsavin
Copy link

gsavin commented Sep 8, 2022

Hi,

I was using the 3.2.4 version, and tried to switch to 3.3.1.
I have a Java interface modeling a D-Bus interface, but there is a difference between package's name, so I am specifying the D-Bus name inside the @DBusInterface value. Something like :

package a.b.c;

@DBusInterface("d.e.f.XXX")
public interface YYY {
...
}

In 3.2.4 this was working fine. If I understood correctly, there was a call to DBusSignal#addInterfaceMap which was adding the mapping. And this was used when creating the signal class in DBusSignal#createSignalClass method. But the call to addInterfaceMap seems to have disappeared in 3.3.1, so the library is trying load the class using the DBus name:

2022-09-08 09:10:42,772 [DBus Worker Thread-3] WARN  o.f.d.c.impl.DBusConnection - Exception while running signal handler 'DBusTestCase$SignalChecker@3ef91466' for signal 'DBusSignal(0,16) { Path=>/d/e/f/xxx/1, Interface=>d.e.f.XXX, Member=>custom_signal, Sender=>:1.1, Signature=>s } { / }':
org.freedesktop.dbus.exceptions.DBusException: Could not create class from signal d.e.f.XXX.CustomSignal
	at org.freedesktop.dbus.messages.DBusSignal.createSignalClass(DBusSignal.java:165)
	at org.freedesktop.dbus.messages.DBusSignal.createReal(DBusSignal.java:181)
	at org.freedesktop.dbus.connections.AbstractConnection$3.run(AbstractConnection.java:911)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:750)

Is it a regression, or is there something new I need to do?

Thanks a lot.

@hypfvieh
Copy link
Owner

hypfvieh commented Sep 8, 2022

A sample project demonstrating the issue would be great.
Anyways I would really recommend to switch to version 4.x as 3.x is no longer under active development and will only receive bug fixes but no further improvements and features.

@gsavin
Copy link
Author

gsavin commented Sep 8, 2022

Quick reply, thanks.

I cannot go for 4.x for now. Project is using Java8, and if I am correct 4.x requires Java11.
It's hard to extract a sample that work, but I will try.

@gsavin
Copy link
Author

gsavin commented Sep 8, 2022

Actually, this problem seems to be only during testing (where I am using the Embedded server). Signals look ok in production mode. So maybe it's more related to an issue with the use of this server.

@hypfvieh
Copy link
Owner

hypfvieh commented Sep 8, 2022

Java 8 is really ancient... 🤮

This may be an regression. I still need a sample which demonstrate the issue, no matter if this is caused by embedded server or the client code. I'm unable to create failing sample based on your information.

@gsavin
Copy link
Author

gsavin commented Sep 8, 2022

Here is a MRE of this problem, but as I said above, it should be more related to the use of the embedded server (sorry looks dirty) :

package a.b.c;

import org.freedesktop.dbus.annotations.DBusInterfaceName;
import org.freedesktop.dbus.annotations.DBusMemberName;
import org.freedesktop.dbus.bin.EmbeddedDBusDaemon;
import org.freedesktop.dbus.connections.BusAddress;
import org.freedesktop.dbus.connections.impl.DBusConnection;
import org.freedesktop.dbus.exceptions.DBusException;
import org.freedesktop.dbus.interfaces.DBusInterface;
import org.freedesktop.dbus.interfaces.DBusSigHandler;
import org.freedesktop.dbus.messages.DBusSignal;
import org.junit.Test;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;

public class SampleTest {
    @DBusInterfaceName("d.e.f.Custom")
    public interface CustomService extends DBusInterface {
        void nothing();

        @DBusMemberName("custom_signal")
        class CustomSignal extends DBusSignal {
            public final String data;

            public CustomSignal(String path, String data) throws DBusException {
                super(path, data);
                this.data = data;
            }
        }
    }

    public static class MyCustomImpl implements CustomService {
        public void nothing() {
            System.out.println("Just doing nothing");
        }

        @Override
        public String getObjectPath() {
            return "/d/e/f/custom";
        }
    }

    @Test
    public void test() throws DBusException, IOException, InterruptedException {
        BusAddress address = new BusAddress("unix:path=/tmp/test-socket");

        try (EmbeddedDBusDaemon daemon = new EmbeddedDBusDaemon()) {
            daemon.setAddress(address);
            daemon.startInBackground();

            Thread.sleep(5_000); // To let the server starts

            DBusConnection connection = DBusConnection.getConnection(address.getRawAddress(), true, true, 10_000);
            connection.requestBusName("d.e.f.Service");
            connection.exportObject("/d/e/f/custom", new MyCustomImpl());

            connection.addSigHandler(CustomService.CustomSignal.class, new DBusSigHandler<CustomService.CustomSignal>() {
                @Override
                public void handle(CustomService.CustomSignal s) {
                    System.out.printf("Received signal: %s%n", s.data);
                }
            });

            connection.sendMessage(new CustomService.CustomSignal("/a/b/c/custom", "hello world"));

            Thread.sleep(5_000);
        } finally {
            Files.deleteIfExists(Paths.get("/tmp/test-socket"));
        }
    }
}

I got it solved by forcing a call to addInterfaceMap before using the signals.

@hypfvieh
Copy link
Owner

hypfvieh commented Sep 8, 2022

Thanks, I'll take a look

@gsavin
Copy link
Author

gsavin commented Sep 8, 2022

Java 8 is really ancient... vomiting_face

Totally agree. This is a first step (don't scream but code was actually Java 7), then we will move for a more respectable Java version.

@hypfvieh
Copy link
Owner

hypfvieh commented Sep 8, 2022

This is indeed a regression introduced somewhere in 2021... I fixed it in 3.3.2 and created a new release. Should hit maven central until tomorrow.

@gsavin
Copy link
Author

gsavin commented Sep 8, 2022

Thanks a lot David!

I gave a try to 3.3.2 and it solved the problem.

@hypfvieh hypfvieh closed this as completed Sep 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants