sd_bus_add_object_manager() excludes the object on its own path

[npmccallum]

Here is the scenario:

sd_bus_add_object_manager(bus, NULL, "/");
sd_bus_add_object_vtable(bus, NULL, "/", "my.first.Interface", vtable, NULL);
sd_bus_add_object_vtable(bus, NULL, "/foo", "my.second.Interface", vtable, NULL);

The first call creates an ObjectManager on "/". The second and third calls create and expose an object on "/" and "/foo", respectively. The ObjectManager exposes "/foo" but NOT "/".

This behavior differs from other implementations. In particular, Bluez expects the ObjectManager on "/" to expose BOTH "/" and "/foo".

[poettering]

I figure gdbus is not in sync on this with what the spec says. I have the suspicion though that the spec should be adjusted to match what gdbus does, rather than the other way round. Hence I filed this now:

https://bugs.freedesktop.org/show_bug.cgi?id=91283

[Alphix]

That's not what I'm seeing. A simple gdbus test case with an object manager at /foo and objects at /foor/bar1 and /foo/bar2 only lists the two objects (like the spec says)

[dvdhrm]

@npmccallum: Care to comment on this?

If BlueZ is the only one doing this wrong, I guess we should follow what gdbus does (and what the spec says) and revert this patch.

[npmccallum]

Bluez defines the expectation here: http://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/gatt-api.txt#n266

Bluez also has working test examples here: http://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-gatt-server

Upon further inspection, it appears they implement ObjectManager themselves incorrectly. See the offending line here: http://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-gatt-server#n91

So I expect that this patch should be reverted and Bluez should be fixed.

[npmccallum]

I have reported the issue here: http://marc.info/?l=linux-bluetooth&m=143836314007389&w=2

[poettering]

We should revert some patches in sd-bus then... reopened.

[Alphix]

Reverting 92d16a5 seems sufficient?

[dvdhrm]

Applied as f2196cf.