dbus: Suppress "Rejecting a message from a wrong sender" error from ObjectManager

dbus: Suppress "Rejecting a message from a wrong sender" error from ObjectManager

The error message was a false alarm that was polluting the log file.

ObjectManager::HandleMessage() is called for *every instance of ObjectManager*
whenever a message is delivered. It's the right thing for an ObjectManager instance
to ignore a signal that the instance is not interested in.

Note that the service owner name change is handled via
ObjectManager::NameOwnerChanged(), that's set up in the ObjectManager's constructor
hence ObjectManager can handle name owner changes.

BUG=507206
TEST=enable/disable Bluetooth and confirm that the error message is no longer emitted in the log file.

Committed: https://crrev.com/9b780e6bfc08404de90339c76ece4457cb1734bc
Cr-Commit-Position: refs/heads/master@{#343656}

[satorux1, 2015-08-17 06:09:12]

satorux@chromium.org changed reviewers:
+ hashimoto@chromium.org

[hashimoto, 2015-08-17 07:07:50]

https://codereview.chromium.org/1297903002/diff/1/dbus/object_manager.cc
File dbus/object_manager.cc (right):

https://codereview.chromium.org/1297903002/diff/1/dbus/object_manager.cc#newc...
dbus/object_manager.cc:213: "type='signal', sender='%s', interface='%s',
member='%s'",
ObjectManager::HandleMessage looks like a dead copy of
ObjectProxy::HandleMessage, and ObjectProxy uses "type='signal', interface='%s',
path='%s'" as the match rule. (why aren't we using
ObjectProxy::ConnectToSignal() here btw?)
Can we use the same (or a similar) match rule to avoid unnecessary
HandleMessage() calls?

[satorux1, 2015-08-17 07:35:07]

https://codereview.chromium.org/1297903002/diff/1/dbus/object_manager.cc
File dbus/object_manager.cc (right):

https://codereview.chromium.org/1297903002/diff/1/dbus/object_manager.cc#newc...
dbus/object_manager.cc:213: "type='signal', sender='%s', interface='%s',
member='%s'",
On 2015/08/17 07:07:49, hashimoto wrote:
> ObjectManager::HandleMessage looks like a dead copy of
> ObjectProxy::HandleMessage, and ObjectProxy uses "type='signal',
interface='%s',
> path='%s'" as the match rule. (why aren't we using
> ObjectProxy::ConnectToSignal() here btw?)
> Can we use the same (or a similar) match rule to avoid unnecessary
> HandleMessage() calls?

Good points, but I'd rather not to do non-trivial refactoring in the CL.

Re the filter rule, it's a great catch that there was a slight difference
(sender='%s' is used here, but not in object_proxy.cc). However, per the finding
at https://code.google.com/p/chromium/issues/detail?id=507206#c14 the object
managers for peerd, privetd, apmanager were receiving signals from bluez for
some reason...

[satorux1, 2015-08-17 08:23:15]

added more comments per offline discussion

[hashimoto, 2015-08-17 08:24:24]

lgtm

[satorux1, 2015-08-17 08:25:29]

The CQ bit was checked by satorux@chromium.org

[commit-bot: I haz the power, 2015-08-17 08:25:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1297903002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1297903002/20001

[commit-bot: I haz the power, 2015-08-17 09:44:42]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-08-17 09:45:23]

Patchset 2 (id:??) landed as
https://crrev.com/9b780e6bfc08404de90339c76ece4457cb1734bc
Cr-Commit-Position: refs/heads/master@{#343656}