hal_initialize() overrides other filter/object/fallback functions on separate connection

[David Zeuthen]

(Followup from a message to the hal mailinglist since this involves
dbus; original message quoted in full)

On Mon, 2004-08-02 at 15:07 -0400, Dan Williams wrote:
> Hi,
> 
> Use the referenced testcase to verify and debug.  Symptom is that if
> hal_initialize is called, filter/object/fallback functions registered on
> another _separate_ DBusConnection never get called.  
> 

Hi,

My tests confirm this is correct; the bug was that the libhal message
filter function always returned DBUS_HANDLER_RESULT_HANDLED even though
we didn't handle the message. Now we return RESULT_NOT_YET_HANDLED for
messages we don't handle (which is less rude). I've committed the fix to
HAL CVS. So now your testcase won't fail.

> Seems to be a dbus problem?
>

I think this is an issue with D-BUS, yes, why would the filter function
in the DBusConnection from libhal receive messages bound for the
DBusConnection made in your main application?

> http://people.redhat.com/dcbw/testcase.tgz
> 
> Reference versions (FC3 Rawhide):
> hal = 0.2.93.cvs20040712-2
> dbus = 0.21.cvs20040722-3
> 
> To verify:
> 
> 1) Untar
> 2) copy client.conf to /etc/dbus-1/system.d
> 3) copy client.conf to /etc/dbus-1/system.d
> 4) restart dbus daemon
> 5) restart hal daemon
> 6) ./autogen.sh
> 7) make
> 8) ./daemon
> 9) ./client
> 10) Look for "SUCCESS!!" from the client, CTRL-C both daemon and client
> 11) Modify the client code to UN-comment the "#define
> MAKE_TESTCASE_FAIL" line (thus hal_initialize() is called)
> 12) make
> 13) ./daemon
> 14) ./client
> 15) Client should not print out SUCCESS!!
> 
> (forgive the detailed instructions...)
> 
> Dan
> 
> _______________________________________________
> hal mailing list
> hal at freedesktop.org
> http://freedesktop.org/mailman/listinfo/hal