[Zope-dev] Specify a domain and leave the password for a user blank
Juan Javier Carrera Obrero
jcarrera at uco.es
Tue Mar 9 07:31:18 EST 2004
Hi,
In Zope 2.4 or older versions when a user is created, if you specify a
domain and leave the password for a user blank, then anyone from the
permitted domains automatically gets the user's roles without having to log
in.
However, it is not possible in Zope 2.7. I have created a user specifying a
domain and leave the password for this user blank, and although I am in the
domain, I have to log in.
Anybody help me about it ? How can I create a user, specifying a domain, and
if the user is in the domain does not have to log in?
Thanks.-
----- Original Message -----
From: <zope-dev-request at zope.org>
To: <zope-dev at zope.org>
Sent: Tuesday, March 09, 2004 12:36 PM
Subject: Zope-Dev Digest, Vol 8, Issue 15
> Send Zope-Dev mailing list submissions to
> zope-dev at zope.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.zope.org/mailman/listinfo/zope-dev
> or, via email, send a message with subject or body 'help' to
> zope-dev-request at zope.org
>
> You can reach the person managing the list at
> zope-dev-owner at zope.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Zope-Dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Re: Unexpected Behaviour iterating over catalog search...
> (Dieter Maurer)
> 2. Zopeservice and sitecustomize (Sake)
> 3. Re: Zopeservice and sitecustomize (Chris McDonough)
> 4. RE: Zopeservice and sitecustomize (Tim Peters)
> 5. RE: Zopeservice and sitecustomize (Tim Peters)
> 6. Re: Re: Unexpected Behaviour iterating over catalog search...
> (Chris Withers)
> 7. Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope
> 2.X BIG Session problems - blocker - our site dies - need help of
> experience Zope developer, please) (Alex V. Koval)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 8 Mar 2004 20:05:04 +0100
> From: Dieter Maurer <dieter at handshake.de>
> Subject: Re: [Zope-dev] Re: Unexpected Behaviour iterating over
> catalog search...
> To: Jean Jordaan <jean at upfrontsystems.co.za>
> Cc: zope-dev at zope.org
> Message-ID: <16460.50144.170406.811279 at gargle.gargle.HOWL>
> Content-Type: text/plain; charset=us-ascii
>
> Jean Jordaan wrote at 2004-3-8 16:33 +0200:
> >>> Surely the thing returned by a Catalog search should be immutable?
> >>
> >> Nope, it is "lazy"; immutability would require "realizing" it first,
> >> which would be prohibitively expensive in many cases.
> >
> >Yes .. thing is, wrapping with list() or tuple() will therefore
> >also be prohibitive in those cases,
>
> When you want to uncatalog everything, "tuple"ing the result should
> not be a problem.
>
> Otherwise, a standard approach is to remember the objects you
> want to delete in a standard list and iterate over this list
> in a separate loop (outside the first one).
>
> --
> Dieter
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 09 Mar 2004 08:54:54 +0700
> From: Sake <sakesun at boonthavorn.com>
> Subject: [Zope-dev] Zopeservice and sitecustomize
> To: zope-dev at zope.org
> Message-ID: <404D23EE.1080702 at boonthavorn.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> I have Zope and Activestate Python installed together in the same win-xp
> machine. Everything works fine until I've learned that I can put
> "sys.setdefaultencoding('cp874')" into sitecustomize.py to accomodate my
> native language coding. Since I do that, my Zope 2.7.0 service can no
> longer start. I can start it manually from "runzope.bat", but it never
> start through the windows system service. A full day investigation
> reveal that the trouble cause by the missing of the
> '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH".
> The "runzope.bat" set that up before then execution of
> "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on
> the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up
> the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py
>
> """ Add Zope packages in Windows binary distro to sys.path automagically
"""
> import sys
> import os
> try:
> sp = __file__
> except:
> sp = None
> if sp:
> dn = os.path.dirname
> swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python')
> if os.path.exists(swhome):
> sys.path.insert(0, swhome)
>
> Unluckily, this sitecustomize.py is now masked with my sitecustomize.py
> inside Activestate's site-package directory, which actually get loaded
> by Zope via the Python registry load path
> (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead
> of the expected one.
>
> I don't think setting up PYTHONPATH inside sitecustomize.py is a good
> idea. Better keep this mechanism for site specific problems. I'd rather
> insert a line into zopeservice.py like this.
>
> import os.path
> from os.path import dirname as dn
> import sys
>
> # these are replacements from mkzopeinstance
> PYTHONW = r'C:\Zope-2.7.0\bin\pythonw.exe'
> SOFTWARE_HOME=r'C:\Zope-2.7.0\lib\python'
> INSTANCE_HOME = r'C:\Zope-MIB'
> ZOPE_HOME = r'C:\Zope-2.7.0'
>
> ZOPE_RUN = r'%s\Zope\Startup\run.py' % SOFTWARE_HOME
> CONFIG_FILE= os.path.join(INSTANCE_HOME, 'etc', 'zope.conf')
> PYTHONSERVICE_EXE=r'%s\bin\PythonService.exe' % ZOPE_HOME
>
> sys.path.insert(0, SOFTWARE_HOME)
> os.environ['PYTHONPATH'] = SOFTWARE_HOME <---------------- inserted line
>
> from nt_svcutils.service import Service
>
> servicename = 'Zope_%s' % str(hash(INSTANCE_HOME))
>
> class InstanceService(Service):
> start_cmd = '"%s" "%s" -C "%s"' % (PYTHONW, ZOPE_RUN, CONFIG_FILE)
> _svc_name_ = servicename
> _svc_display_name_ = 'Zope instance at %s' % INSTANCE_HOME
> _exe_name_ = PYTHONSERVICE_EXE
>
> if __name__ == '__main__':
> import win32serviceutil
> win32serviceutil.HandleCommandLine(InstanceService)
>
>
>
> This is much more palatable in my opinion.
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 08 Mar 2004 22:14:10 -0500
> From: Chris McDonough <chrism at plope.com>
> Subject: Re: [Zope-dev] Zopeservice and sitecustomize
> To: Sake <sakesun at boonthavorn.com>
> Cc: zope-dev at zope.org
> Message-ID: <1078802050.12387.38.camel at athlon>
> Content-Type: text/plain
>
> On Mon, 2004-03-08 at 20:54, Sake wrote:
>
> > Everything works fine until I've learned that I can put
> > "sys.setdefaultencoding('cp874')" into sitecustomize.py
>
> I assume you created a new sitecustomize.py to hold this in your
> activestate Python's library directory, then?
>
> > I can start it manually from "runzope.bat", but it never
> > start through the windows system service. A full day investigation
> > reveal that the trouble cause by the missing of the
> > '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH".
> > The "runzope.bat" set that up before then execution of
> > "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on
> > the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up
> > the correct "PYTHONPATH". Here is the code inside Zope's
sitecustomize.py
>
> This was put here because in my tests I could not make Python recognize
> the "right" set of paths by setting an environment variable in the
> zopeservice script.
>
> As you probably noticed, Zope does not run in the same Python
> interpreter instance as the one that zopeservice.py runs under.
> zopeservice.py instead turns around and invokes another Python
> interpreter to actually do the running of Zope itself (that's what
> "start_cmd" is set for). Worse, the windows Service code actually
> doesn't invoke zopeservice.py directly; it is run as a side effect of
> the PythonService.exe executable being run. Setting a PYTHONPATH via
> os.environ in zopeservice was not doing the trick for me (at least on
> Win2K); why was unclear, although I think it was because the environment
> being modified by setting os.environ within zopeservice is not carried
> over to child processes. A batch file couldn't be used as the target
> for the service because the Windows shell doesn't keep track of child
> processes in the same way UNIX does: child processes aren't killed when
> their parents are and there is no way to 'exec' another command from a
> Windows batch file.
>
> > Unluckily, this sitecustomize.py is now masked with my sitecustomize.py
> > inside Activestate's site-package directory, which actually get loaded
> > by Zope via the Python registry load path
> > (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead
> > of the expected one.
>
> I don't think I understand why this happens. That's not surprising.
> There is some complicated DWIM that Windows Python does when it starts
> up to try to guess what should go on sys.path and in what order. Tim
> Peters dug up a comment in Python's code and sent it to me a bit ago
> about why this happens. It can be found in Python's PC/getpathp.c file:
>
> PATH RULES FOR WINDOWS:
> This describes how sys.path is formed on Windows. It describes the
> functionality, not the implementation (ie, the order in which these
> are actually fetched is different)
>
> * Python always adds an empty entry at the start, which corresponds
> to the current directory.
>
> * If the PYTHONPATH env. var. exists, it's entries are added next.
>
> * We look in the registry for "application paths" - that is, sub-keys
> under the main PythonPath registry key. These are added next (the
> order of sub-key processing is undefined).
> HKEY_CURRENT_USER is searched and added first.
> HKEY_LOCAL_MACHINE is searched and added next.
> (Note that all known installers only use HKLM, so HKCU is typically
> empty)
>
> * We attempt to locate the "Python Home" - if the PYTHONHOME env var
> is set, we believe it. Otherwise, we use the path of our host
> .EXE's
> to try and locate our "landmark" (lib\\os.py) and deduce our home.
> - If we DO have a Python Home: The relevant sub-directories (Lib,
> plat-win, lib-tk, etc) are based on the Python Home
> - If we DO NOT have a Python Home, the core Python Path is
> loaded from the registry. This is the main PythonPath key,
> and both HKLM and HKCU are combined to form the path)
>
> * Iff - we can not locate the Python Home, have not had a PYTHONPATH
> specified, and can't locate any Registry entries (ie, we have
> _nothing_
> we can assume is a good path), a default path with relative entries
> is
> used (eg. .\Lib;.\plat-win, etc)
>
> The end result of all this is:
> * When running python.exe, or any other .exe in the main Python
> directory
> (either an installed version, or directly from the PCbuild
> directory),
> the core path is deduced, and the core paths in the registry are
> ignored. Other "application paths" in the registry are always read.
>
> * When Python is hosted in another exe (different directory, embedded
> via
> COM, etc), the Python Home will not be deduced, so the core path
> from
> the registry is used. Other "application paths" in the registry are
> always read.
>
> * If Python can't find its home and there is no registry (eg, frozen
> exe, some very strange installation setup) you get a path with
> some default, but relative, paths.
>
> >From this (and without a Windows machine in front of me), I can't really
> make any sense out of why your Activestate Python's sitecustomize.py is
> being found instead of Zope's Python sitecustomize.py if you're running
> Zope using the Zope Python install. I suspect it may be because of
> placement of your sitecustomize.py file and the rule named "We look in
> the registry for "application paths"", but that's a guess.
>
> > I don't think setting up PYTHONPATH inside sitecustomize.py is a good
> > idea. Better keep this mechanism for site specific problems. I'd rather
> > insert a line into zopeservice.py like this.
> >
> > import os.path
> > from os.path import dirname as dn
> > import sys
> >
> > # these are replacements from mkzopeinstance
> > PYTHONW = r'C:\Zope-2.7.0\bin\pythonw.exe'
> > SOFTWARE_HOME=r'C:\Zope-2.7.0\lib\python'
> > INSTANCE_HOME = r'C:\Zope-MIB'
> > ZOPE_HOME = r'C:\Zope-2.7.0'
> >
> > ZOPE_RUN = r'%s\Zope\Startup\run.py' % SOFTWARE_HOME
> > CONFIG_FILE= os.path.join(INSTANCE_HOME, 'etc', 'zope.conf')
> > PYTHONSERVICE_EXE=r'%s\bin\PythonService.exe' % ZOPE_HOME
> >
> > sys.path.insert(0, SOFTWARE_HOME)
> > os.environ['PYTHONPATH'] = SOFTWARE_HOME <---------------- inserted
line
> >
> > from nt_svcutils.service import Service
> >
> > servicename = 'Zope_%s' % str(hash(INSTANCE_HOME))
> >
> > class InstanceService(Service):
> > start_cmd = '"%s" "%s" -C "%s"' % (PYTHONW, ZOPE_RUN, CONFIG_FILE)
> > _svc_name_ = servicename
> > _svc_display_name_ = 'Zope instance at %s' % INSTANCE_HOME
> > _exe_name_ = PYTHONSERVICE_EXE
> >
> > if __name__ == '__main__':
> > import win32serviceutil
> > win32serviceutil.HandleCommandLine(InstanceService)
> >
> >
> >
> > This is much more palatable in my opinion.
>
> Does this work? On all of W2K, Win98, and WinXP? If so, I'd be glad to
> ditch the current munging of sitecustomize.py. As I said, it wasn't
> working for me, at least on Win2K.
>
> - C
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 8 Mar 2004 22:27:27 -0500
> From: "Tim Peters" <tim at zope.com>
> Subject: RE: [Zope-dev] Zopeservice and sitecustomize
> To: "Sake" <sakesun at boonthavorn.com>
> Cc: zope-dev at zope.org
> Message-ID: <LNBBLJKPBEHFEDALKOLCEEFJJGAB.tim at zope.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> [Sake]
> > I have Zope and Activestate Python installed together in the same
> > win-xp machine. Everything works fine until I've learned that I can
> > put "sys.setdefaultencoding('cp874')" into sitecustomize.py to
> > accomodate my native language coding. Since I do that, my Zope 2.7.0
> > service can no longer start. I can start it manually from
> > "runzope.bat", but it never start through the windows system service.
> > A full day investigation reveal that the trouble cause by the missing
> > of the '<SOFTWARE_HOME>\lib\python' in the system environment's
> > "PYTHONPATH". The "runzope.bat" set that up before then execution of
> > "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on
> > the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up
> > the correct "PYTHONPATH". Here is the code inside Zope's
> > sitecustomize.py
> >
> > """ Add Zope packages in Windows binary distro to sys.path
> > automagically """ import sys
> > import os
> > try:
> > sp = __file__
> > except:
> > sp = None
> > if sp:
> > dn = os.path.dirname
> > swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python')
> > if os.path.exists(swhome):
> > sys.path.insert(0, swhome)
> >
> > Unluckily, this sitecustomize.py is now masked with my
> > sitecustomize.py inside Activestate's site-package directory, which
> > actually get loaded by Zope via the Python registry load path
> > (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead
> > of the expected one.
>
> It's actually a different bug: Python normally never looks at the value
of
> the PythonPath registry key, and that's not why your sitecustomize.py is
> found first. That's actually a side effect of ActiveState installing
> win32all: if you look *under*
> HKLM\Software\Python\PythonCore\2.3\PythonPath, you'll find subkeys
> Pythonwin, win32, and win32com. It's actually the win32com subkey that
puts
> your ActiveState Python's lib\site-packages into sys.path. It's then a
bug
> in Zope that it lets that dirty trick hide its own lib\site-packages:
Zope
> ships with its own Python, and *intends* to insulate you completely (in
both
> directions) from whatever other Python(s) you may happen to have installed
> on the machine. So when that bug gets fixed, your sitecustomize.py will
> never get executed.
>
> BTW, sys.setdefaultencoding() is almost never a good solution; working
with
> Unicode instead usually is.
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 8 Mar 2004 22:35:20 -0500
> From: "Tim Peters" <tim at zope.com>
> Subject: RE: [Zope-dev] Zopeservice and sitecustomize
> To: "Chris McDonough" <chrism at plope.com>, "Sake"
> <sakesun at boonthavorn.com>
> Cc: zope-dev at zope.org
> Message-ID: <LNBBLJKPBEHFEDALKOLCOEFKJGAB.tim at zope.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> [Chris McDonough]
> > ...
> > From this (and without a Windows machine in front of me), I can't
> > really make any sense out of why your Activestate Python's
> > sitecustomize.py is being found instead of Zope's Python
> > sitecustomize.py if you're running Zope using the Zope Python install.
> > I suspect it may be because of placement of your sitecustomize.py file
> > and the rule named "We look in the registry for "application paths"",
> > but that's a guess.
>
> Yes, and the "application path" is specifically win32com, which
ActiveState
> installed. That has the side effect of putting the ActiveState Python's
> Lib/site-packages into sys.path, and it so happens that it ends up before
> Zope's Lib/site-packages. That's why Sake's sitecustomize.py is found
> first. It also so happens that all of ActiveState's win32all appears
before
> any of Zope's attempt to supply its own win32all, so there are multiple
bugs
> here. AFIAK, these subtle sys.path glitches are in all of Zope Corp's
> Windows offerings, except for the very recent ZRS-for-Windows 1.4 release.
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 09 Mar 2004 10:21:31 +0000
> From: Chris Withers <lists at simplistix.co.uk>
> Subject: Re: [Zope-dev] Re: Unexpected Behaviour iterating over
> catalog search...
> To: Jean Jordaan <jean at upfrontsystems.co.za>
> Cc: zope-dev at zope.org
> Message-ID: <404D9AAB.6020001 at simplistix.co.uk>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Jean Jordaan wrote:
>
> > for brain in Catalog(some_index=some_value):
> > # delete the object, and then
> > brain_to_delete = Catalog(unique_index=brain.unique_prop)
> > Catalog.uncatalog_object(brain_to_delete.getPath())
> >
> > .. can't really think why that would work if Chris's original
> > doesn't, though.
>
> ...it won't, this is analagous to the code I have that fails.
>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Zope & Python Consulting
> - http://www.simplistix.co.uk
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 09 Mar 2004 13:36:33 +0200
> From: "Alex V. Koval" <alex at halogen-dg.com>
> Subject: Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope
> 2.X BIG Session problems - blocker - our site dies - need help of
> experience Zope developer, please)
> To: "Chris McDonough" <chrism at plope.com>
> Cc: zope-dev at zope.org
> Message-ID: <opr4lei7llb959jf at alex.halogen.kharkov.ua>
> Content-Type: text/plain; charset="koi8-r"
>
>
> Hi Chris,
>
> On Fri, 05 Mar 2004 13:08:01 -0500, Chris McDonough <chrism at plope.com>
> wrote:
>
> >> I am monitoring site now, and will tell you about the results.
> > OK, many thanks!
>
> Running For: 3 days 4 hours 28 min 29 sec.
>
> I have enabled 400 error_log ex exceptions to keep, and during 3 days I
> got 2 errors
> on the site:
>
> Time Username (User Id) Exception
> 16:35:01 Anonymous User (None) KeyError: 1078763620
> 21:59:05 Anonymous User (None) KeyError: 1078696720
>
> But it seems I forget to install new Transience module to the new Zope
> instance. Should I?
>
> --
> Alex V. Koval
> http://www.halogen-dg.com
> http://www.zwarehouse.org
> -------------- next part --------------
> Traceback (innermost last):
> Module ZPublisher.Publish, line 100, in publish
> Module ZPublisher.mapply, line 88, in mapply
> Module ZPublisher.Publish, line 40, in call_object
> Module OFS.DTMLDocument, line 128, in __call__
> - <DTMLDocument instance at 41c05e90>
> - URL: http://www.chalkface.com/custom/index_html/manage_main
> - Physical Path: /www.chalkface.com/ZWarehouse_0.8/custom/index_html
> Module DocumentTemplate.DT_String, line 474, in __call__
> Module OFS.DTMLDocument, line 121, in __call__
> - <DTMLDocument instance at 41c0a440>
> - URL: http://www.chalkface.com/custom/index.html/manage_main
> - Physical Path: /www.chalkface.com/ZWarehouse_0.8/custom/index.html
> Module DocumentTemplate.DT_String, line 474, in __call__
> Module DocumentTemplate.DT_Let, line 76, in render
> Module OFS.DTMLDocument, line 121, in __call__
> - <DTMLDocument instance at 41be5290>
> - URL:
http://www.chalkface.com/catalog/html/zwarehouse_html_header/manage_main
> - Physical Path:
/www.chalkface.com/ZWarehouse_0.8/catalog/html/zwarehouse_html_header
> Module DocumentTemplate.DT_String, line 474, in __call__
> Module DocumentTemplate.DT_Util, line 201, in eval
> - __traceback_info__: cart_functions
> Module <string>, line 1, in <expression>
> Module Shared.DC.Scripts.Bindings, line 306, in __call__
> Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec
> Module Products.PythonScripts.PythonScript, line 318, in _exec
> Module None, line 16, in setSessionByRequest.py
> - <PythonScript at
/www.chalkface.com/ZWarehouse_0.8/catalog/cart_functions/setSessionByRequest
.py>
> - Line 16
> Module ZPublisher.HTTPRequest, line 1218, in __getattr__
> Module ZPublisher.HTTPRequest, line 1178, in get
> Module Products.Sessions.SessionDataManager, line 93, in getSessionData
> Module Products.Sessions.SessionDataManager, line 180, in
_getSessionDataObject
> Module Products.Transience.Transience, line 176, in new_or_existing
> Module Products.Transience.Transience, line 809, in get
> KeyError: 1078696720
> -------------- next part --------------
> Traceback (innermost last):
> Module ZPublisher.Publish, line 100, in publish
> Module ZPublisher.mapply, line 88, in mapply
> Module ZPublisher.Publish, line 40, in call_object
> Module OFS.DTMLDocument, line 128, in __call__
> - <DTMLDocument instance at 41c0a440>
> - URL: http://www.chalkface.com/custom/index.html/manage_main
> - Physical Path: /www.chalkface.com/ZWarehouse_0.8/custom/index.html
> Module DocumentTemplate.DT_String, line 474, in __call__
> Module DocumentTemplate.DT_Let, line 76, in render
> Module OFS.DTMLDocument, line 121, in __call__
> - <DTMLDocument instance at 41be5290>
> - URL:
http://www.chalkface.com/catalog/html/zwarehouse_html_header/manage_main
> - Physical Path:
/www.chalkface.com/ZWarehouse_0.8/catalog/html/zwarehouse_html_header
> Module DocumentTemplate.DT_String, line 474, in __call__
> Module DocumentTemplate.DT_Util, line 201, in eval
> - __traceback_info__: cart_functions
> Module <string>, line 1, in <expression>
> Module Shared.DC.Scripts.Bindings, line 306, in __call__
> Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec
> Module Products.PythonScripts.PythonScript, line 318, in _exec
> Module None, line 16, in setSessionByRequest.py
> - <PythonScript at
/www.chalkface.com/ZWarehouse_0.8/catalog/cart_functions/setSessionByRequest
.py>
> - Line 16
> Module ZPublisher.HTTPRequest, line 1218, in __getattr__
> Module ZPublisher.HTTPRequest, line 1178, in get
> Module Products.Sessions.SessionDataManager, line 93, in getSessionData
> Module Products.Sessions.SessionDataManager, line 180, in
_getSessionDataObject
> Module Products.Transience.Transience, line 176, in new_or_existing
> Module Products.Transience.Transience, line 809, in get
> KeyError: 1078763620
>
> ------------------------------
>
> _______________________________________________
> Zope-Dev maillist - Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
>
> (To receive general Zope announcements, see:
> http://mail.zope.org/mailman/listinfo/zope-announce
>
> For non-developer, user-level issues,
> zope at zope.org, http://mail.zope.org/mailman/listinfo/zope )
>
> End of Zope-Dev Digest, Vol 8, Issue 15
> ***************************************
More information about the Zope-Dev
mailing list