impossible to remove S&D from a Zope instance

Bug #682172 reported by Toni Mueller
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Singing & Dancing
New
Undecided
Unassigned

Bug Description

Trying to remove S&D from a Plone instance does not work, and causes severe damage to a Plone 4.x site:

1. Add S&D to your buildout, run buildout, add S&D to a Plone site (eg. via the PMI).
2. Deinstall S&D from the PMI, or from the ZMI using the portal_quickinstaller
3. Remove S&D from the buildout and run buildout again.
4. Fire up the instance to see error messages like this (I'm not sure that this is exhaustive, but have only seen this error message in my latest attempt):

2010-11-27 17:39:34 ERROR Zope.SiteErrorLog 1290875974.340.563496530955 http://localhost:9082/01/mnt/Plone
Traceback (innermost last):
  Module ZPublisher.Publish, line 116, in publish
  Module ZPublisher.BaseRequest, line 434, in traverse
  Module ZPublisher.BeforeTraverse, line 99, in __call__
  Module Products.CMFCore.PortalObject, line 78, in __before_publishing_traverse__
  Module zope.event, line 23, in notify
  Module zope.component.event, line 26, in dispatch
  Module zope.component._api, line 138, in subscribers
  Module zope.component.registry, line 323, in subscribers
  Module zope.interface.adapter, line 575, in subscribers
  Module zope.component.event, line 33, in objectEventNotify
  Module zope.component._api, line 138, in subscribers
  Module zope.component.registry, line 323, in subscribers
  Module zope.interface.adapter, line 575, in subscribers
  Module plone.browserlayer.layer, line 14, in mark_layer
  Module zope.component._api, line 181, in getAllUtilitiesRegisteredFor
  Module zope.component.registry, line 178, in getAllUtilitiesRegisteredFor
  Module ZODB.Connection, line 838, in setstate
  Module ZODB.Connection, line 906, in _setstate
  Module ZODB.serialize, line 629, in setGhostState
  Module ZODB.serialize, line 622, in getState
  Module copy_reg, line 48, in _reconstructor
TypeError: ('object.__new__(Salt) is not safe, use persistent.Persistent.__new__()', <function _reconstructor at 0x829995c>, (<class 'collective.dancing.channel.Salt'>, <type 'object'>, None))
2010-11-27 17:39:34 ERROR ZODB.Connection Couldn't load state for 0x02e1
Traceback (most recent call last):
  File "/home/zope/eggs/ZODB3-3.9.5-py2.6-linux-i686.egg/ZODB/Connection.py", line 838, in setstate
    self._setstate(obj)
  File "/home/zope/eggs/ZODB3-3.9.5-py2.6-linux-i686.egg/ZODB/Connection.py", line 906, in _setstate
    self._reader.setGhostState(obj, p)
  File "/home/zope/eggs/ZODB3-3.9.5-py2.6-linux-i686.egg/ZODB/serialize.py", line 629, in setGhostState
    state = self.getState(pickle)
  File "/home/zope/eggs/ZODB3-3.9.5-py2.6-linux-i686.egg/ZODB/serialize.py", line 622, in getState
    return unpickler.load()
  File "/home/zope/vplone4/lib/python2.6/copy_reg.py", line 48, in _reconstructor
    obj = object.__new__(cls)
TypeError: ('object.__new__(Salt) is not safe, use Persistence.Persistent.__new__()', <function _reconstructor at 0x829995c>, (<class 'collective.dancing.channel.Salt'>, <type 'object'>, None))

In effect, this prevents me from accessing the Plone site ("Site Error"), and it even prevents me from removing the Plone site via the ZMI.

I tried with Plone 4.0.1 and 4.0.2, and with S&D 0.9.0 and 0.9.2. Because of the impact of this problem, I'd say that the bug deserved a state of "important" or higher (don't know what's available exactly with LP).

Revision history for this message
petschki (petschki) wrote :

Hi, i just ran into the same problem and found a quick'n'dirty workaround for this:

1. add "collective.dancing" and "wildcard.fixpersistentutilities" to your buildout eggs
2. run buildout and start instance
3. go to "http://your/plone/@@fix-persistent-utilities" in your browser
4. remove everything with "ISalt" interfaces via the small dash at the end of the line
5. remove both eggs, re-run buildout and start your instance

your instance now runs properly without s&d

please note, that with "wildcard.fixpersistentutilities" you can really screw up your instance. read more on http://blog.fourdigits.nl/removing-a-persistent-local-utility-part-ii and http://pypi.python.org/pypi/wildcard.fixpersistentutilities

good luck

Revision history for this message
ddavout (danielle-davout) wrote :

Thanks Peter for sharing your workaround but I would like one more piece of advice ...
Should I remove as well
<InterfaceClass collective.singing.async.IQueue>

<InterfaceClass collective.singing.async.IQueue> [ - ]
    collective.dancing.jobs - <collective.singing.async.Queue object at 0x69d95f0> [ - ]
?

Revision history for this message
Maurits van Rees (maurits-vanrees) wrote :

Yes, I would say: remove every interface that starts with collective.dancing or collective.singing.

Revision history for this message
petschki (petschki) wrote :

+1 maurits :)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.