[Zope-dev] Specify a domain and leave the password for a user
blank
Andreas Jung
andreas at andreas-jung.com
Tue Mar 9 07:33:24 EST 2004
I think you are describing a flaw that had been removed in older versions.
Does not sound like a feature but like a bug...
-aj
--On Dienstag, 9. März 2004 13:31 Uhr +0100 Juan Javier Carrera Obrero
<jcarrera at uco.es> wrote:
> 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/setSessionByRequ
> est .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/setSessionByRequ
> est .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
>> ***************************************
>
>
> _______________________________________________
> Zope-Dev maillist - Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )
More information about the Zope-Dev
mailing list