[z3-five] [Plone-Users] plone/zope conflict errors and <at> <at> plone attribute error

[Alec Mitchell]

On 9/19/06, Alec Mitchell <apm13 at columbia.edu> wrote:
> On 9/19/06, Philipp von Weitershausen <philipp at weitershausen.de> wrote:
> > Alec Mitchell wrote:
> > > On 9/19/06, Philipp von Weitershausen <philipp at weitershausen.de> wrote:
> > >> Alec Mitchell wrote:
> > >> Do we have proof that this is Five's fault, IOW, that the request is
> > >> *actually* missing IDefaultBrowserLayer? Or is this just an assumption?
> > >> Alec, is this a reasonably recent Zope 2.9 installation?
> > >
> > > Not necessarily that it's Five's fault but that IDefaultBrowserLayer
> > > is missing from the request, I determined/confirmed this in a pdb
> > > session after triggering a ConflictError.  If I manually applied that
> > > interface to the request during the pdb session using alsoProvides
> > > then the request succeeded, otherwise I got an AttributeError.  This
> > > is 2.9.4-final with Five-1.4 svn, I have not really attempted to
> > > reproduce this on 2.9 svn though.
> >
> > Ok, that's exactly what I was wondering. Thanks for making that clearer.
> >
> > >> In general, the rule is that whoever creates the request also has to
> > >> apply the default skins. We modified the ZPublisher to do that. It could
> > >> be that due to the retry functionality that is invoked before
> > >> ConflictErrors occur, a new request w/o the default skin is created. In
> > >> that case the problem is within ZPublisher's retry functionality.
> > >
> > > That sounds pretty likely.  Can we fix this for Zope 2.9.5?
> >
> > Sure. You have my gracious permission to do so ;)
>
> Well that much I figured, of course I have very little idea where to
> start looking on this one.

OK, looks like the fix is easy enough (a new request is being
generated on retry in Publish.py, so we apply the skin to it), the
test is probably going to be a bit trickier though. ;-)

Alec