zope.component getUtility doesn't return instance attributes

[Jean Jordaan]

I was having an issue with `hl.plone.boardnotifications` that mails were not being queued, despite queueing being specified via the ZMI.

At the debug prompt, the issue looks like this:

```
>>> mh = getUtility(IMailHost)
>>> mh
<MailHost at /plone/MailHost>
>>> app.plone.MailHost
<MailHost at /plone/MailHost>
>>> mh.smtp_queue
False
>>> app.plone.MailHost.smtp_queue
True
```

A working hack was to replace this line `mh = getUtility(IMailHost)`
with this:

```
        site = getUtility(ISiteRoot)
        mh = site.MailHost
```

Somehow the `smtp_queue` attribute is getting lost when the mailhost is being looked up as utility, but not when it is found by attribute access.

[Wolfgang Schnerring (wosc)]

Without more context it's hard so tell, but this looks like it might be a hierarchy issue.

zope.component.getUtility() uses the "current site" to look up utilities, so it might well be that the global registry has one MailHost instance registered as a utility (which has smtp_queue=False), and your site has another instance registered (which has smtp_queue=True), and then somewhere there's a mixup about what the current site should be when looking up the utility.

But as I said, that's just a wild guess.

[Wolfgang Schnerring (wosc)]

What looks suspcicious is that both times it says "MailHost at /plone/MailHost>, so maybe my guess is bogus. To check my hypothesis, you could compare the object ids, like so:

>>> id(getUtility(IMailHost))
>>> id(app.plone.MailHost)

[Jean Jordaan (jean-jordaan)]

On Wed, Feb 5, 2014 at 1:36 PM, Wolfgang Schnerring <email address hidden> wrote:
> What looks suspcicious is that both times it says "MailHost at
> /plone/MailHost>, so maybe my guess is bogus. To check my hypothesis,
> you could compare the object ids, like so:
>
>>>> id(getUtility(IMailHost))
>>>> id(app.plone.MailHost)

You are correct, they are different objects, although they appear to be the
same:

    >>> mh = getUtility(IMailHost)
    >>> mh.smtp_queue
    False
    >>> app.plone.MailHost.smtp_queue
    True
    >>> id(mh)
    204573148
    >>> id(app.plone.MailHost)
    204571508
    >>> mh
    <MailHost at /plone/MailHost>
    >>> app.plone.MailHost
    <MailHost at /plone/MailHost>

This is also the case if I put a breakpoint at the point where mail is sent:

    > .../hl.plone.boardnotifications/hl/plone/boardnotifications/notify.py(285)_notify()
    -> mh.send(msg)
    (Pdb) l
    282 mh = getUtility(IMailHost)
    283 site = getUtility(ISiteRoot)
    284 import pdb; pdb.set_trace()
    285 -> mh.send(msg)
    286
    (Pdb) id(mh)
    219056884
    (Pdb) id(site.MailHost)
    219652044

--
jean . .. .... //\\\oo///\\

[Wolfgang Schnerring (wosc)]

Alright, so I'm afraid I'll have to say, this is very probably not a bug in zope.component, but rather a problem with either your specific Plone instance, or some misconfiguration issue between some packages you are using. You might want to contact the plone-users mailing list or something like that, they might be able to help you figure this out (I know virtually nothing about Plone).

[Jean Jordaan (jean-jordaan)]

Dieter Maurer explains exactly what's going wrong at http://sourceforge.net/mailarchive/forum.php?thread_name=874n4ceki9.fsf%40handshake.de&forum_name=plone-users

In short:

> Note that this is not a Zope3 bug. It is more a CMF design or a "five.localsitemanager" implementation bug.