Re: [Zope3-dev] Persistent declarations, dead interfaces and a TypeError
On Feb 22, 2007, at 8:24 PM, Sidnei da Silva wrote:
Hi there,
I'm consistently having issues with 'directlyProvides' and interfaces
that are moved or removed. The symptom is that when the persisted
declaration is unghostified a TypeError happens.
This is specially bad since in this case the 'directlyProvides' is
being used on a PAS plugin, and the TypeError prevents the user from
even going into the ZMI to delete the object!
Here's a snippet of the traceback. In the list of interfaces below,
the ones prefixed by Products.Five.bbb do not exist anymore:
Module ZODB.Connection, line 732, in setstate
Module ZODB.Connection, line 786, in _setstate
Module ZODB.serialize, line 604, in setGhostState
Module ZODB.serialize, line 597, in getState
Module zope.interface.declarations, line 766, in Provides
Module zope.interface.declarations, line 669, in __init__
Module zope.interface.declarations, line 47, in __init__
Module zope.interface.declarations, line 1363, in _normalizeargs
Module zope.interface.declarations, line 1362, in _normalizeargs
TypeError: ('iteration over non-sequence', function Provides at
0x009A6F70, (class
'Products.PluggableAuthService.plugins.ScriptablePlugin.ScriptablePlug
in',
InterfaceClass persistent.interfaces.IPersistent, class
'Products.Five.bbb.OFS_interfaces.IFolder', class
'Products.Five.bbb.OFS_interfaces.IObjectManager', InterfaceClass
zope.app.container.interfaces.IContainer, class
'Products.Five.bbb.OFS_interfaces.ICopyContainer', class
'Products.Five.bbb.App_interfaces.INavigation', class
'Products.Five.bbb.Acquisition_interfaces.IAcquirer', class
'Products.Five.bbb.webdav_interfaces.IDAVCollection', class
'Products.Five.bbb.webdav_interfaces.IDAVResource', class
'Products.Five.bbb.webdav_interfaces.IWriteLock', class
'Products.Five.bbb.OFS_interfaces.ITraversable', class
'Products.Five.bbb.OFS_interfaces.IPropertyManager', class
'Products.Five.bbb.AccessControl_interfaces.IRoleManager', class
'Products.Five.bbb.AccessControl_interfaces.IPermissionMappingSupport'
,
class 'Products.Five.bbb.OFS_interfaces.IItem', class
'Products.Five.bbb.OFS_interfaces.ICopySource', class
'Products.Five.bbb.AccessControl_interfaces.IOwned', class
'Products.Five.bbb.App_interfaces.IUndoSupport', class
'Products.Five.bbb.OFS_interfaces.IFindSupport', class
'Products.Five.bbb.OFS_interfaces.ISimpleItem', InterfaceClass
Products.PluggableAuthService.interfaces.plugins.IAuthenticationPlugin
,
InterfaceClass
Products.PluggableAuthService.interfaces.plugins.IExtractionPlugin))
I believe that _normalizeargs in zope.interface.declarations should be
changed to cope with this, by ignoring those 'broken' references.
Thoughts?
I think this should be handled in the declaration serialization code.
We should arrange that when a declaration is unpickled we:
- catch interfaces that can't be loaded,
- issue a warning
- replace the wayward interface with some kind of placeholder.
This may require checking for broken objects rather than catching
errors.
This is largely hand waving, but I think the overall approach is
sound. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Persistent declarations, dead interfaces and a TypeError
On 2/23/07, Jim Fulton [EMAIL PROTECTED] wrote: I think this should be handled in the declaration serialization code. We should arrange that when a declaration is unpickled we: - catch interfaces that can't be loaded, Apparently when the interface can't be loaded it turns from a InterfaceClass to a 'class', which doesn't conform to the iteration protocol expected by the 'for v in sequence' in _normalizeargs. Would detecting a standard 'class' vs 'InterfaceClass' be enough? - issue a warning Not too fond of that. :) - replace the wayward interface with some kind of placeholder. Like a BrokenInterfacleClass? This may require checking for broken objects rather than catching errors. This is largely hand waving, but I think the overall approach is sound. :) It sounds good to me. In fact it's pretty much what I had in mind, except for the warning. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Persistent declarations, dead interfaces and a TypeError
FWIW, this is already a BrokenClass instance, thanks to ZODB: (Pdb) p sequence class 'Products.Five.bbb.OFS_interfaces.IFolder' (Pdb) p sequence.__mro__ (class 'Products.Five.bbb.OFS_interfaces.IFolder', class 'OFS.Uninstalled.BrokenClass', type 'ExplicitAcquirer', class 'OFS.SimpleItem.Item', class 'webdav.Resource.Resource', class webdav.Lockable.LockableItem at 0x014C6630, class webdav.EtagSupport.EtagSupport at 0x014C6600, class 'OFS.CopySupport.CopySource', class 'App.Management.Tabs', class OFS.Traversable.Traversable at 0x01431120, class OFS.ZDOM.Element at 0x014D7330, class OFS.ZDOM.Node at 0x014D7270, class 'AccessControl.Owned.Owned', class 'App.Undo.UndoSupport', type 'Persistence.Persistent', type 'persistent.Persistent', type 'ExtensionClass.Base', type 'object') Wonder if we can just check for that? And then how to avoid a dependency of zope.interface on OFS.Uninstalled.BrokenClass. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Persistent declarations, dead interfaces and a TypeError
Sidnei da Silva wrote at 2007-2-23 12:08 -0300: ... Wonder if we can just check for that? And then how to avoid a dependency of zope.interface on OFS.Uninstalled.BrokenClass. You can positively check that the object is an Interface subclass. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Persistent declarations, dead interfaces and a TypeError
On 2/23/07, Dieter Maurer [EMAIL PROTECTED] wrote: Sidnei da Silva wrote at 2007-2-23 12:08 -0300: ... Wonder if we can just check for that? And then how to avoid a dependency of zope.interface on OFS.Uninstalled.BrokenClass. You can positively check that the object is an Interface subclass. Well, the correct check there is 'Interface' subclass *or* iterable. In fact it blindly assumes that if it's not an 'Interface' subclass then it's an iterable. That's actually the issue. I don't think there's an easy 'isiterable' check other than catching TypeError? -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Persistent declarations, dead interfaces and a TypeError
Hi there,
I'm consistently having issues with 'directlyProvides' and interfaces
that are moved or removed. The symptom is that when the persisted
declaration is unghostified a TypeError happens.
This is specially bad since in this case the 'directlyProvides' is
being used on a PAS plugin, and the TypeError prevents the user from
even going into the ZMI to delete the object!
Here's a snippet of the traceback. In the list of interfaces below,
the ones prefixed by Products.Five.bbb do not exist anymore:
Module ZODB.Connection, line 732, in setstate
Module ZODB.Connection, line 786, in _setstate
Module ZODB.serialize, line 604, in setGhostState
Module ZODB.serialize, line 597, in getState
Module zope.interface.declarations, line 766, in Provides
Module zope.interface.declarations, line 669, in __init__
Module zope.interface.declarations, line 47, in __init__
Module zope.interface.declarations, line 1363, in _normalizeargs
Module zope.interface.declarations, line 1362, in _normalizeargs
TypeError: ('iteration over non-sequence', function Provides at
0x009A6F70, (class
'Products.PluggableAuthService.plugins.ScriptablePlugin.ScriptablePlugin',
InterfaceClass persistent.interfaces.IPersistent, class
'Products.Five.bbb.OFS_interfaces.IFolder', class
'Products.Five.bbb.OFS_interfaces.IObjectManager', InterfaceClass
zope.app.container.interfaces.IContainer, class
'Products.Five.bbb.OFS_interfaces.ICopyContainer', class
'Products.Five.bbb.App_interfaces.INavigation', class
'Products.Five.bbb.Acquisition_interfaces.IAcquirer', class
'Products.Five.bbb.webdav_interfaces.IDAVCollection', class
'Products.Five.bbb.webdav_interfaces.IDAVResource', class
'Products.Five.bbb.webdav_interfaces.IWriteLock', class
'Products.Five.bbb.OFS_interfaces.ITraversable', class
'Products.Five.bbb.OFS_interfaces.IPropertyManager', class
'Products.Five.bbb.AccessControl_interfaces.IRoleManager', class
'Products.Five.bbb.AccessControl_interfaces.IPermissionMappingSupport',
class 'Products.Five.bbb.OFS_interfaces.IItem', class
'Products.Five.bbb.OFS_interfaces.ICopySource', class
'Products.Five.bbb.AccessControl_interfaces.IOwned', class
'Products.Five.bbb.App_interfaces.IUndoSupport', class
'Products.Five.bbb.OFS_interfaces.IFindSupport', class
'Products.Five.bbb.OFS_interfaces.ISimpleItem', InterfaceClass
Products.PluggableAuthService.interfaces.plugins.IAuthenticationPlugin,
InterfaceClass
Products.PluggableAuthService.interfaces.plugins.IExtractionPlugin))
I believe that _normalizeargs in zope.interface.declarations should be
changed to cope with this, by ignoring those 'broken' references.
Thoughts?
--
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
