[z3-five] ConnectionStateError: Shouldn't load state for 0x04 when the connection is closed

[Rocky Burt]

Hi Yuppie,

On Sun, 2006-30-07 at 20:45 +0200, yuppie wrote:
> Hi Rocky!
> 
> 
> Rocky Burt wrote:
> > On Sat, 2006-29-07 at 20:26 +0200, Philipp von Weitershausen wrote:
> >> yuppie wrote:
> >>> Index: pythonproducts.py
> >>> ===================================================================
> >>> --- pythonproducts.py	(Revision 69227)
> >>> +++ pythonproducts.py	(Arbeitskopie)
> >>> @@ -124,7 +124,7 @@
> >>>           product=self.aq_acquire('_getProducts')()._product(name)
> >>>
> >>>           # Try to get a custom dispatcher from a Python product
> >>> -        productPkgs = product_packages(app)
> >>> +        productPkgs = product_packages(self.getPhysicalRoot())
> >>>           dispatcher_class=getattr(
> >>>               productPkgs.get(name, None),
> >>>               '__FactoryDispatcher__',
> >>>
> >>>
> >>> You are invited to test this patch and to report back if it causes any 
> >>> trouble. If the patch solves the problem without creating new problems 
> >>> it should be checked in.
> >> Seems like the patch has been verified to work. Yuppie, Rocky, ...?
> > 
> > Hmm, I seem to recall trying something like this and the tests failing.
> > If the tests pass I'd say its a decent short-term patch.  But
> > realistically I should update the application context handling a bit
> > better in general.  Thankfully this support isn't needed with Five 1.5.
> 
> I don't understand your last sentence. AFAICS this support was just 
> partly moved from Five to Zope and is still needed.
> 
> I was not aware of the fact that Zope 2.10 uses a different 
> implementation. After looking at that code I have the impression that 
> you just forgot to backport the new code to Five 1.4. The Five 1.5 and 
> Zope 2.10 code looks much better than the broken code in Five 1.4. My 
> patch doesn't remove all dependencies on the nasty _zope_app variable.
> 
> I choose getPhysicalRoot() because I'm not sure how expensive it is to 
> open a new connection. But Zope2.app() as used in Zope 2.10 works as 
> well and I can't see a reason for a short-term solution that is different.

I implemented the support in Five 1.4 first.  Then later on I
implemented it into zope 2.10 after I had gained a bit more experience.
The approach I used in zope 2.10 was cleaner, indeed ... but I didn't
realize the approach used in Five 1.4 would cause problems.  Basically
you're right, I need to backport the approach from Zope 2.10 into Five
1.4.  The problem is that right now I'm in the middle of a move and its
hard for me to do anything beyond a tiny bit of client work.

I will get to this eventually though.  Unless of course some brave soul
wants to do it first :)

- Rocky

-- 
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://codespeak.net/pipermail/z3-five/attachments/20060730/17199689/attachment.pgp