Registering event-handler in CompenentRegistry - a good idea? (refs plone.multilingual)

Hi,

while debugging a massive performance lag in plone.multilingualbehavior,
I stumbled across a general problem. It leads me to doubt that
registering an event handler in the component registry (as opposed to
registering in zcml) is a good idea (using Plone 4.3.2).

Explanation:
I will use plone.multilingualbehavior as an example, where an event
handler is registered via Generic Setup [1].
One of the principles of GS is idempotence, i.e. you can run an import
step multiple times, and the result is always the same. To be concrete,
the event handler should be present in the component registry exactly
once, no matter how often the GS profile is applied. And indeed, GS
_seems_ to guarantee this: The handler is first unregistered, then
registered again.  [2]

But the unregistering fails in Plone 4.3.2. To understand this, we need
to look at zope.component in the version used by Plone 4.3.2, which is
3.9.5. The unregisterHandler() method is the key: [3]

In short, it takes a list of interfaces (param "required") and a
factory. It searches through its own handler registration and throws out
all existing registrations that match both the factory and the list of
required interfaces.

The problem lies in comparing the factory. Every time GS calls
unregisterHandler(), it has built a _new_ instance of the factory, which
will never match any factory in the list of existing registrations.

As a result, every run of GS (for the componentregistry step) will add a
new handler registration, not replace an existing one.

If the __class__ were use for comparing, instead of the factory itself,
unregistering would work. Proof of concept: [4]


My questions:

* Known issue, or should I file a bug report for GS?

* Generally speaking: What is the use of registering event handlers (and
also adapters) in the component registry? Is there any benefit over
registration via zcml (i.e. on startup)? In my experience, persisting
configuration in the ZODB puts a high demand for clean un-install on the
package that does it. Especially since the component registry is a piece
of black magic, and even more so the
zope.interface.adapter.AdapterRegistry. - Easy to overlook something.

I've had too many cases of a broken site after removal of some package
code due to persistent utilities or other persistent components in the
past years to be a fan of this approach.

Opinions?

Cheers,
Wolfgang / pysailor



[1]
https://github.com/plone/plone.multilingualbehavior/blob/master/plone/multilingualbehavior/profiles/default/componentregistry.xml#L4
[2]
https://github.com/zopefoundation/Products.GenericSetup/blob/master/Products/GenericSetup/components.py#L259
[3]
https://github.com/zopefoundation/zope.component/blob/3.9.5/src/zope/component/registry.py#L344
[4]
https://github.com/plone/plone.multilingualbehavior/blob/use_editfinishedevent/plone/multilingualbehavior/upgrades/upgrades.py#L39

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers