RFC: Acquisition and __parent__ pointers
This proposal aims at bringing Zope 2 a bit closer to Zope 3 by making the widely used Acquisition API aware of Zope 3's __parent__ pointers. This will alleviate the need of using Acquisition base classes in Zope 2 for every security-sensitive object, be it persistent or just a dynamically looked up component such as a view. The goal is to enable the use of Zope 3 components in Zope 2 straight away without creating subclasses that mix in Acquisition for security's sake. See http://wiki.zope.org/zope2/AcquisitionAndParentPointers for the full proposal. Comments are appreciated. I expect little resistance to this as it pretty much doesn't change any existing semantics and just makes all of our lives much simpler. Also, if it helps, this has been blessed by Jim in discussion at the EuroPython 2006 sprint. As for the implementation, I gave it my best shot in the philikon-aq-and-__parent__ branch. My experience with C is limited, especially when it comes to debugging. Help is therefore highly appreciated. There's a reward waiting for whoever fixes the problem and helps getting the branch merged to the trunk (see the proposal text). :) -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
On Wed, 2007-24-01 at 01:02 +0100, Philipp von Weitershausen wrote:
As for the implementation, I gave it my best shot in the philikon-aq-and-__parent__ branch. My experience with C is limited, especially when it comes to debugging. Help is therefore highly appreciated. There's a reward waiting for whoever fixes the problem and helps getting the branch merged to the trunk (see the proposal text).
While I don't have the time (and probably not the C experience) required to help resolve this... I strongly support it getting completed :) So +1 from me. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net
Philipp von Weitershausen wrote:
This proposal aims at bringing Zope 2 a bit closer to Zope 3 by making the widely used Acquisition API aware of Zope 3's __parent__ pointers. This will alleviate the need of using Acquisition base classes in Zope 2 for every security-sensitive object, be it persistent or just a dynamically looked up component such as a view. The goal is to enable the use of Zope 3 components in Zope 2 straight away without creating subclasses that mix in Acquisition for security's sake.
See http://wiki.zope.org/zope2/AcquisitionAndParentPointers for the full proposal. Comments are appreciated. I expect little resistance to this as it pretty much doesn't change any existing semantics and just makes all of our lives much simpler. Also, if it helps, this has been blessed by Jim in discussion at the EuroPython 2006 sprint.
Very strong +1 from me The biggest pain in my ass when coding for Zope 2 these days is that I want to use views and I have to understand a lot of detail about how acquisition works to avoid strange and hard-to-debug errors. If I could stop mixing Acquisition.Explicit into my views, life would be so much better. As for the implementation, I gave it my best shot in the philikon-aq-and-__parent__ branch. My experience with C is limited, especially when it comes to debugging. Help is therefore highly appreciated. There's a reward waiting for whoever fixes the problem and helps getting the branch merged to the trunk (see the proposal text). I guess this is the challenge. Who wants to code C? :) Who even understand this code? (looking at people like Jim and Dieter...) Martin -- View this message in context: http://www.nabble.com/RFC%3A-Acquisition-and-__parent__-pointers-tf3078248.h... Sent from the Zope - Dev mailing list archive at Nabble.com.
Hi, I had a few minutes to spare and took a quick look at the implementation. Philipp von Weitershausen wrote:
As for the implementation, I gave it my best shot in the philikon-aq-and-__parent__ branch. My experience with C is limited, especially when it comes to debugging. Help is therefore highly appreciated. There's a reward waiting for whoever fixes the problem and helps getting the branch merged to the trunk (see the proposal text).
I don't know any C (the only thing I ever did code in C was a simple wrapper script to actually call Solaris assembler ;) but nonetheless I thought I might be able to give some hints to the person that tries to fix this. Here's what I found regarding the segfault. All the segfaults come from tests in Products.Five. The first one that dumped core for me was the last test in Five/formlib/tests/formlib.txt in line 76. After a bit of debugging I found that it actually fails while trying to set a new object into a folder. As the folder where the object should be set into is derived from OFS.Folder it will call OFS.ObjectManager.checkValidId and fail on line 96 at: obj = getattr(self, id, None) My pdb session told me this: (Pdb) self <FiveTraversableFolder at /test_folder_1_/ftf> (Pdb) id 'test123' (Pdb) self.objectIds() ['content_1'] But more importantly: (Pdb) self.aq_chain [<FiveTraversableFolder at /test_folder_1_/ftf>, <Products.Five.metaclass.AddContentForm object at 0x30554d0>] (Pdb) self.__parent__ <Products.Five.metaclass.AddContentForm object at 0x30554d0> (Pdb) self.__parent__.__parent__ <FiveTraversableFolder at /test_folder_1_/ftf> (Pdb) self.__parent__.__parent__.__parent__ <Products.Five.metaclass.AddContentForm object at 0x30554d0> (Pdb) self.aq_parent <Products.Five.metaclass.AddContentForm object at 0x30554d0> (Pdb) self.aq_parent.aq_parent *** AttributeError: aq_parent So somehow the Acquisition chain got messed up and the getattr call gets down into an infinite loop, which will cause the segfault after some time. I hope this helps somebody to fix the actual problem, Hanno
participants (4)
-
Hanno Schlichting -
Martin Aspeli -
Philipp von Weitershausen -
Rocky Burt