[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/Transience/Transience.py remove unused import.

[Chris Withers]

Log message for revision 40465:
  remove unused import.

Changed:
  U   Zope/trunk/lib/python/Products/Transience/Transience.py

-=-
Modified: Zope/trunk/lib/python/Products/Transience/Transience.py
===
--- Zope/trunk/lib/python/Products/Transience/Transience.py 2005-12-02 
10:36:37 UTC (rev 40464)
+++ Zope/trunk/lib/python/Products/Transience/Transience.py 2005-12-02 
12:10:29 UTC (rev 40465)
@@ -36,7 +36,6 @@
 
 from Persistence import Persistent
 from OFS.SimpleItem import SimpleItem
-from ZPublisher.Publish import Retry
 from AccessControl import ClassSecurityInfo, getSecurityManager
 from AccessControl.SecurityManagement import newSecurityManager, \
  setSecurityManager

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/ZServer/ moved FCGI deprecation warning into FCGIServerFactory

[Andreas Jung]

Log message for revision 40467:
  moved FCGI deprecation warning into FCGIServerFactory
  

Changed:
  U   Zope/trunk/lib/python/ZServer/FCGIServer.py
  U   Zope/trunk/lib/python/ZServer/datatypes.py

-=-
Modified: Zope/trunk/lib/python/ZServer/FCGIServer.py
===
--- Zope/trunk/lib/python/ZServer/FCGIServer.py 2005-12-02 13:29:46 UTC (rev 
40466)
+++ Zope/trunk/lib/python/ZServer/FCGIServer.py 2005-12-02 13:35:48 UTC (rev 
40467)
@@ -48,10 +48,6 @@
 import thread
 from types import StringTypes
 
-import warnings
-warnings.warn(Using FastCGI is deprecated. You should use mod_proxy  +
-  to run Zope with Apache, DeprecationWarning)
-
 tz_for_log = compute_timezone_for_log()
 
 #--

Modified: Zope/trunk/lib/python/ZServer/datatypes.py
===
--- Zope/trunk/lib/python/ZServer/datatypes.py  2005-12-02 13:29:46 UTC (rev 
40466)
+++ Zope/trunk/lib/python/ZServer/datatypes.py  2005-12-02 13:35:48 UTC (rev 
40467)
@@ -132,6 +132,12 @@
 
 class FCGIServerFactory(ServerFactory):
 def __init__(self, section):
+
+import warnings
+warnings.warn(Using FastCGI is deprecated. You should use mod_proxy  
+
+  to run Zope with Apache, DeprecationWarning)
+
+
 import socket
 if section.address.family == socket.AF_INET:
 address = section.address.address

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/OFS/SimpleItem.py - change to use python logging module

[Chris Withers]

Log message for revision 40468:
  - change to use python logging module
  - log at error when standard_error_message can't be rendered
  - give more useful info about errors rendering standard_error_message to the 
browser.

Changed:
  U   Zope/trunk/lib/python/OFS/SimpleItem.py

-=-
Modified: Zope/trunk/lib/python/OFS/SimpleItem.py
===
--- Zope/trunk/lib/python/OFS/SimpleItem.py 2005-12-02 13:35:48 UTC (rev 
40467)
+++ Zope/trunk/lib/python/OFS/SimpleItem.py 2005-12-02 13:45:58 UTC (rev 
40468)
@@ -32,12 +32,12 @@
 from AccessControl.ZopeSecurityPolicy import getRoles
 from Acquisition import aq_base, aq_parent, aq_inner, aq_acquire
 from ComputedAttribute import ComputedAttribute
+from DocumentTemplate.html_quote import html_quote
 from DocumentTemplate.ustr import ustr
 from ExtensionClass import Base
 from webdav.Resource import Resource
 from zExceptions import Redirect
 from zExceptions.ExceptionFormatter import format_exception
-from zLOG import LOG, BLATHER
 from zope.interface import implements
 
 import ZDOM
@@ -49,6 +49,8 @@
 
 HTML=Globals.HTML
 
+import logging
+logger = logging.getLogger()
 
 class Item(Base, Resource, CopySource, App.Management.Tabs, Traversable,
ZDOM.Element,
@@ -226,17 +228,21 @@
 else:
 v = HTML.__call__(s, client, REQUEST, **kwargs)
 except:
-LOG('OFS', BLATHER,
+logger.error(
 'Exception while rendering an error message',
-error=sys.exc_info())
+exc_info=True
+)
 try:
 strv = str(error_value)
 except:
-strv = ('unprintable %s object' %
+strv = ('unprintable %s object' % 
 str(type(error_value).__name__))
 v = strv + (
- (Also, an error occurred while attempting 
-to render the standard error message.))
+( (Also, the following error occurred while attempting 
+ to render the standard error message, please see the 
+ event log for full details: %s))%(
+html_quote(sys.exc_info()[1]),
+))
 raise error_type, v, tb
 finally:
 if hasattr(self, '_v_eek'): del self._v_eek

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.9/ deprecated FastCGI

[Andreas Jung]

Log message for revision 40469:
  deprecated FastCGI
  

Changed:
  U   Zope/branches/2.9/doc/CHANGES.txt
  U   Zope/branches/2.9/doc/WEBSERVER.txt
  U   Zope/branches/2.9/lib/python/ZServer/datatypes.py

-=-
Modified: Zope/branches/2.9/doc/CHANGES.txt
===
--- Zope/branches/2.9/doc/CHANGES.txt   2005-12-02 13:45:58 UTC (rev 40468)
+++ Zope/branches/2.9/doc/CHANGES.txt   2005-12-02 13:49:55 UTC (rev 40469)
@@ -26,6 +26,8 @@
 
 Features added
 
+  - Using FastCGI is officially deprecated
+
   - Improved logging of ConflictErrors. Now a log is made at level
 BLATHER with traceback for any conflict retried. In addition, a
 log is made at level ERROR for a conflict that can't be retried

Modified: Zope/branches/2.9/doc/WEBSERVER.txt
===
--- Zope/branches/2.9/doc/WEBSERVER.txt 2005-12-02 13:45:58 UTC (rev 40468)
+++ Zope/branches/2.9/doc/WEBSERVER.txt 2005-12-02 13:49:55 UTC (rev 40469)
@@ -110,6 +110,8 @@
 
  FastCGI
 
+  FastCGI is deprecated and should not be used anymore.
+
   FastCGI is relatively easy to set up if you have installed an Apache
   module before.  If you haven't, don't worry, it isn't difficult.  It
   comes with straightforward instructions.  You will need to download

Modified: Zope/branches/2.9/lib/python/ZServer/datatypes.py
===
--- Zope/branches/2.9/lib/python/ZServer/datatypes.py   2005-12-02 13:45:58 UTC 
(rev 40468)
+++ Zope/branches/2.9/lib/python/ZServer/datatypes.py   2005-12-02 13:49:55 UTC 
(rev 40469)
@@ -132,6 +132,11 @@
 
 class FCGIServerFactory(ServerFactory):
 def __init__(self, section):
+
+import warnings
+warnings.warn(Using FastCGI is deprecated. You should use mod_proxy  
+  to run Zope with Apache, DeprecationWarning)
+
 import socket
 if section.address.family == socket.AF_INET:
 address = section.address.address

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Z further changes to ConflictError logging:

[Chris Withers]

Log message for revision 40472:
  further changes to ConflictError logging:
  - all conflict errors are counted and logged at info, as they were before 
Florent's change
  - logging makes it clear where the conflict has been resolved and where it 
hasn't
  - errors seen by the user are rendered with standard_error_message and are 
sent to the error_log which will likely copy them to the event log, depending 
on the users setup.
  - also checking in a functional test for generating write conflict errors.
  
  (I'll be committing to CHANGES.TXT shortly, I just wanted to keep the merges 
simpler)

Changed:
  A   Zope/trunk/lib/python/ZPublisher/tests/generate_conflicts.py
  U   Zope/trunk/lib/python/Zope2/App/startup.py

-=-
Added: Zope/trunk/lib/python/ZPublisher/tests/generate_conflicts.py
===
--- Zope/trunk/lib/python/ZPublisher/tests/generate_conflicts.py
2005-12-02 14:34:07 UTC (rev 40471)
+++ Zope/trunk/lib/python/ZPublisher/tests/generate_conflicts.py
2005-12-02 14:35:08 UTC (rev 40472)
@@ -0,0 +1,91 @@
+## This script requires:
+## - python2.4
+## - Zope 3's zope.testbrowser package:
+##   http://www.zope.org/Members/benji_york/ZopeTestbrowser-0.9.0.tgz
+##
+## The just run:
+## $python2.4 generate_conflicts.py
+import base64
+import string
+import threading
+import urllib2
+
+from zope.testbrowser.browser import Browser
+
+# create our browser
+class AuthBrowser(Browser):
+
+def addBasicAuth(self,username,password):
+self.addHeader(
+'Authorization',
+'Basic '+base64.encodestring(username+':'+password).strip()
+)
+
+def open(self,uri,include_server=True):
+if include_server:
+uri = server+uri
+return Browser.open(self,uri)
+
+browser = AuthBrowser()
+
+# constants
+server = 'http://localhost:8080'
+# the following user must be able to view the management screens
+# and create file objects
+username = 'username'
+password = 'password'
+browser.addBasicAuth(username,password)
+threads = 10
+filename = 'conflict.txt'
+filesize = 1
+hits = 5
+
+# delete the file if it's already there
+browser.open('/manage_main')
+if filename in [c.optionValue
+for c in browser.getControl(name='ids:list').controls]:
+browser.open('/manage_delObjects?ids:list='+filename)
+
+# create it
+browser.open('/manage_addFile?id='+filename)
+
+# edit it, hopefully causing conflicts
+data = 'X'*filesize
+class EditThread(threading.Thread):
+
+def __init__(self,i):
+self.conflicts = 0
+self.browser = AuthBrowser()
+self.browser.handleErrors = False
+self.browser.addBasicAuth(username,password)
+threading.Thread.__init__(self,name=str(i))
+
+def run(self):
+for i in range(1,hits+1):
+self.browser.open('/conflict.txt/manage_main')
+self.browser.getControl(name='title').value='Test Title'
+self.browser.getControl(name='filedata:text').value = data
+try:
+self.browser.getControl(name='manage_edit:method').click()
+except urllib2.HTTPError,e:
+# print e.read()
+self.conflicts += 1
+print Thread %s - CONFLICT % self.getName()
+else:
+print Thread %s - EDIT % self.getName()
+
+thread_objects = []
+for i in range(1,threads+1):
+t = EditThread(i)
+thread_objects.append(t)
+t.start()
+for t in thread_objects:
+t.join()
+total = 0
+print
+for t in thread_objects:
+print Thread %s - %i conflicts seen % (t.getName(),t.conflicts)
+total += t.conflicts
+print
+print %i conflicts seen by browsers % total
+


Property changes on: 
Zope/trunk/lib/python/ZPublisher/tests/generate_conflicts.py
___
Name: svn:eol-style
   + native

Modified: Zope/trunk/lib/python/Zope2/App/startup.py
===
--- Zope/trunk/lib/python/Zope2/App/startup.py  2005-12-02 14:34:07 UTC (rev 
40471)
+++ Zope/trunk/lib/python/Zope2/App/startup.py  2005-12-02 14:35:08 UTC (rev 
40472)
@@ -18,9 +18,9 @@
 from AccessControl.SecurityManagement import noSecurityManager
 from Acquisition import aq_acquire
 from App.config import getConfiguration
+from time import asctime
 from types import StringType, ListType
 from zExceptions import Unauthorized
-from zLOG import LOG, ERROR, WARNING, INFO, BLATHER, log_time
 from ZODB.POSException import ConflictError
 import transaction
 import AccessControl.User
@@ -28,6 +28,7 @@
 import ExtensionClass
 import Globals
 import imp
+import logging
 import OFS.Application
 import os
 import sys
@@ -103,7 +104,7 @@
 noSecurityManager()
 
 global startup_time
-startup_time = log_time()
+startup_time = asctime()
 
 Zope2.zpublisher_transactions_manager = TransactionsManager()
  

[Zope-Checkins] SVN: Zope/trunk/lib/python/Zope2/App/startup.py *sigh* failed to correctly merge my own patch.

[Chris Withers]

Log message for revision 40475:
  *sigh* failed to correctly merge my own patch.

Changed:
  U   Zope/trunk/lib/python/Zope2/App/startup.py

-=-
Modified: Zope/trunk/lib/python/Zope2/App/startup.py
===
--- Zope/trunk/lib/python/Zope2/App/startup.py  2005-12-02 14:45:53 UTC (rev 
40474)
+++ Zope/trunk/lib/python/Zope2/App/startup.py  2005-12-02 15:10:44 UTC (rev 
40475)
@@ -221,6 +221,7 @@
 finally:
 traceback=None
 
+ac_logger = logging.getLogger('event.AccessControl')
 
 class TransactionsManager:
 def begin(self,
@@ -237,7 +238,7 @@
 def recordMetaData(self, object, request,
# Optimize global var lookups:
hasattr=hasattr, getattr=getattr,
-   LOG=LOG, WARNING=WARNING,
+   logger=ac_logger,
):
 request_get = request.get
 if hasattr(object, 'getPhysicalPath'):

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/lib/python/ Merge error reporting changes from trunk:

[Chris Withers]

Log message for revision 40476:
  Merge error reporting changes from trunk:
  
  - remove unused import.
  - change SimpleItem.py to use python logging module
  - log at error when standard_error_message can't be rendered
  - give more useful info about errors rendering standard_error_message to the 
browser.
  - all conflict errors are counted and logged at info
  - logging makes it clear where the conflict has been resolved and where it 
hasn't
  - errors seen by the user are rendered with standard_error_message and are 
sent to the error_log which will likely copy them to the event log, depending 
on the users setup.
  - also checking in a functional test for generating write conflict errors.

  (I'll be committing to CHANGES.TXT shortly, I just wanted to keep the merges 
simpler)

Changed:
  U   Zope/branches/Zope-2_8-branch/lib/python/OFS/SimpleItem.py
  U   Zope/branches/Zope-2_8-branch/lib/python/Products/Transience/Transience.py
  A   
Zope/branches/Zope-2_8-branch/lib/python/ZPublisher/tests/generate_conflicts.py
  U   Zope/branches/Zope-2_8-branch/lib/python/Zope2/App/startup.py

-=-
Modified: Zope/branches/Zope-2_8-branch/lib/python/OFS/SimpleItem.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/OFS/SimpleItem.py  2005-12-02 
15:10:44 UTC (rev 40475)
+++ Zope/branches/Zope-2_8-branch/lib/python/OFS/SimpleItem.py  2005-12-02 
15:44:31 UTC (rev 40476)
@@ -30,10 +30,10 @@
 from AccessControl import getSecurityManager, Unauthorized
 from AccessControl.ZopeSecurityPolicy import getRoles
 from Acquisition import aq_base, aq_parent, aq_inner, aq_acquire
+from DocumentTemplate.html_quote import html_quote
 from DocumentTemplate.ustr import ustr
 from zExceptions.ExceptionFormatter import format_exception
 from zExceptions import Redirect
-from zLOG import LOG, BLATHER
 
 from CopySupport import CopySource
 from Traversable import Traversable
@@ -41,6 +41,8 @@
 
 HTML=Globals.HTML
 
+import logging
+logger = logging.getLogger()
 
 class Item(Base, Resource, CopySource, App.Management.Tabs, Traversable,
ZDOM.Element,
@@ -210,17 +212,21 @@
 else:
 v = HTML.__call__(s, client, REQUEST, **kwargs)
 except:
-LOG('OFS', BLATHER,
+logger.error(
 'Exception while rendering an error message',
-error=sys.exc_info())
+exc_info=True
+)
 try:
 strv = str(error_value)
 except:
 strv = ('unprintable %s object' % 
 str(type(error_value).__name__))
 v = strv + (
- (Also, an error occurred while attempting 
-to render the standard error message.))
+( (Also, the following error occurred while attempting 
+ to render the standard error message, please see the 
+ event log for full details: %s))%(
+html_quote(sys.exc_info()[1]),
+))
 raise error_type, v, tb
 finally:
 if hasattr(self, '_v_eek'): del self._v_eek

Modified: 
Zope/branches/Zope-2_8-branch/lib/python/Products/Transience/Transience.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/Products/Transience/Transience.py  
2005-12-02 15:10:44 UTC (rev 40475)
+++ Zope/branches/Zope-2_8-branch/lib/python/Products/Transience/Transience.py  
2005-12-02 15:44:31 UTC (rev 40476)
@@ -36,7 +36,6 @@
 
 from Persistence import Persistent
 from OFS.SimpleItem import SimpleItem
-from ZPublisher.Publish import Retry
 from AccessControl import ClassSecurityInfo, getSecurityManager
 from AccessControl.SecurityManagement import newSecurityManager, \
  setSecurityManager

Copied: 
Zope/branches/Zope-2_8-branch/lib/python/ZPublisher/tests/generate_conflicts.py 
(from rev 40472, Zope/trunk/lib/python/ZPublisher/tests/generate_conflicts.py)


Property changes on: 
Zope/branches/Zope-2_8-branch/lib/python/ZPublisher/tests/generate_conflicts.py
___
Name: svn:eol-style
   + native

Modified: Zope/branches/Zope-2_8-branch/lib/python/Zope2/App/startup.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/Zope2/App/startup.py   
2005-12-02 15:10:44 UTC (rev 40475)
+++ Zope/branches/Zope-2_8-branch/lib/python/Zope2/App/startup.py   
2005-12-02 15:44:31 UTC (rev 40476)
@@ -18,9 +18,9 @@
 from AccessControl.SecurityManagement import noSecurityManager
 from Acquisition import aq_acquire
 from App.config import getConfiguration
+from time import asctime
 from types import StringType, ListType
 from zExceptions import Unauthorized
-from zLOG import LOG, WARNING, INFO, BLATHER, 

[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/ - remove unused import.

[Chris Withers]

Log message for revision 40478:
- remove unused import.
- change SimpleItem.py to use python logging module
- log at error when standard_error_message can't be rendered
- give more useful info about errors rendering standard_error_message to 
the browser.
- all conflict errors are counted and logged at info
- logging makes it clear where the conflict has been resolved and where it 
hasn't
- errors seen by the user are rendered with standard_error_message and are 
sent to the error_log which will likely copy them to the event log, depending 
on the users setup.
- also checking in a functional test for generating write conflict errors.
  
(I'll be committing to CHANGES.TXT shortly, I just wanted to keep the 
merges simpler)

Changed:
  U   Zope/branches/2.9/lib/python/OFS/SimpleItem.py
  U   Zope/branches/2.9/lib/python/Products/Transience/Transience.py
  A   Zope/branches/2.9/lib/python/ZPublisher/tests/generate_conflicts.py
  U   Zope/branches/2.9/lib/python/Zope2/App/startup.py

-=-
Modified: Zope/branches/2.9/lib/python/OFS/SimpleItem.py
===
--- Zope/branches/2.9/lib/python/OFS/SimpleItem.py  2005-12-02 15:46:29 UTC 
(rev 40477)
+++ Zope/branches/2.9/lib/python/OFS/SimpleItem.py  2005-12-02 15:52:43 UTC 
(rev 40478)
@@ -29,12 +29,12 @@
 from AccessControl.ZopeSecurityPolicy import getRoles
 from Acquisition import aq_base, aq_parent, aq_inner, aq_acquire
 from ComputedAttribute import ComputedAttribute
+from DocumentTemplate.html_quote import html_quote
 from DocumentTemplate.ustr import ustr
 from ExtensionClass import Base
 from webdav.Resource import Resource
 from zExceptions import Redirect
 from zExceptions.ExceptionFormatter import format_exception
-from zLOG import LOG, BLATHER
 from zope.interface import implements
 
 import ZDOM
@@ -46,6 +46,8 @@
 
 HTML=Globals.HTML
 
+import logging
+logger = logging.getLogger()
 
 class Item(Base, Resource, CopySource, App.Management.Tabs, Traversable,
ZDOM.Element,
@@ -222,17 +224,21 @@
 else:
 v = HTML.__call__(s, client, REQUEST, **kwargs)
 except:
-LOG('OFS', BLATHER,
+logger.error(
 'Exception while rendering an error message',
-error=sys.exc_info())
+exc_info=True
+)
 try:
 strv = str(error_value)
 except:
 strv = ('unprintable %s object' %
 str(type(error_value).__name__))
 v = strv + (
- (Also, an error occurred while attempting 
-to render the standard error message.))
+( (Also, the following error occurred while attempting 
+ to render the standard error message, please see the 
+ event log for full details: %s))%(
+html_quote(sys.exc_info()[1]),
+))
 raise error_type, v, tb
 finally:
 if hasattr(self, '_v_eek'): del self._v_eek

Modified: Zope/branches/2.9/lib/python/Products/Transience/Transience.py
===
--- Zope/branches/2.9/lib/python/Products/Transience/Transience.py  
2005-12-02 15:46:29 UTC (rev 40477)
+++ Zope/branches/2.9/lib/python/Products/Transience/Transience.py  
2005-12-02 15:52:43 UTC (rev 40478)
@@ -36,7 +36,6 @@
 
 from Persistence import Persistent
 from OFS.SimpleItem import SimpleItem
-from ZPublisher.Publish import Retry
 from AccessControl import ClassSecurityInfo, getSecurityManager
 from AccessControl.SecurityManagement import newSecurityManager, \
  setSecurityManager

Copied: Zope/branches/2.9/lib/python/ZPublisher/tests/generate_conflicts.py 
(from rev 40476, 
Zope/branches/Zope-2_8-branch/lib/python/ZPublisher/tests/generate_conflicts.py)


Property changes on: 
Zope/branches/2.9/lib/python/ZPublisher/tests/generate_conflicts.py
___
Name: svn:eol-style
   + native

Modified: Zope/branches/2.9/lib/python/Zope2/App/startup.py
===
--- Zope/branches/2.9/lib/python/Zope2/App/startup.py   2005-12-02 15:46:29 UTC 
(rev 40477)
+++ Zope/branches/2.9/lib/python/Zope2/App/startup.py   2005-12-02 15:52:43 UTC 
(rev 40478)
@@ -18,9 +18,9 @@
 from AccessControl.SecurityManagement import noSecurityManager
 from Acquisition import aq_acquire
 from App.config import getConfiguration
+from time import asctime
 from types import StringType, ListType
 from zExceptions import Unauthorized
-from zLOG import LOG, ERROR, WARNING, INFO, BLATHER, log_time
 from ZODB.POSException import ConflictError
 import transaction
 import AccessControl.User
@@ -28,6 +28,7 @@
 import 

[Zope-Checkins] SVN: Zope/branches/2.9/doc/CHANGES.txt Note changes to ConflictError logging.

[Chris Withers]

Log message for revision 40479:
  Note changes to ConflictError logging.

Changed:
  U   Zope/branches/2.9/doc/CHANGES.txt

-=-
Modified: Zope/branches/2.9/doc/CHANGES.txt
===
--- Zope/branches/2.9/doc/CHANGES.txt   2005-12-02 15:52:43 UTC (rev 40478)
+++ Zope/branches/2.9/doc/CHANGES.txt   2005-12-02 15:54:13 UTC (rev 40479)
@@ -28,11 +28,12 @@
 
   - Using FastCGI is officially deprecated
 
-  - Improved logging of ConflictErrors. Now a log is made at level
-BLATHER with traceback for any conflict retried. In addition, a
-log is made at level ERROR for a conflict that can't be retried
-anymore and is returned to the browser as an error. Nothing is
-logged anymore at level INFO.
+  - Improved logging of ConflictErrors. All conflict errors are
+logged at INFO, with counts of how many occurred and how many
+were resolved. Tracebacks for all conflicts are logged a DEBUG
+level, although these won't help anyone much. If a conflict
+error is unresolved, it will now bubble up to error_log and
+standard_error_message.
 
   - Fixed unclear security declarations. Warn when an attempt is
 made to have a security declaration on a nonexistent method.

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PageTemplates/PageTemplate.py continue whack-a-mole'ing useless pagetemplate errors.

[Chris Withers]

Log message for revision 40480:
  continue whack-a-mole'ing useless pagetemplate errors.

Changed:
  U   Zope/trunk/lib/python/Products/PageTemplates/PageTemplate.py

-=-
Modified: Zope/trunk/lib/python/Products/PageTemplates/PageTemplate.py
===
--- Zope/trunk/lib/python/Products/PageTemplates/PageTemplate.py
2005-12-02 15:54:13 UTC (rev 40479)
+++ Zope/trunk/lib/python/Products/PageTemplates/PageTemplate.py
2005-12-02 15:58:14 UTC (rev 40480)
@@ -131,7 +131,11 @@
 self._cook()
 if self._v_errors:
 __traceback_supplement__ = (PageTemplateTracebackSupplement, self)
-raise PTRuntimeError, 'Page Template %s has errors.' % self.id
+raise PTRuntimeError, (
+'Page Template %s has errors: %s' % (
+self.id,
+self._v_errors
+))
 return self._v_macros
 
 def pt_source_file(self):

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/Products/PageTemplates/PageTemplate.py continue whack-a-mole'ing useless pagetemplate errors.

[Chris Withers]

Log message for revision 40481:
  continue whack-a-mole'ing useless pagetemplate errors.
  

Changed:
  U   Zope/branches/2.9/lib/python/Products/PageTemplates/PageTemplate.py

-=-
Modified: Zope/branches/2.9/lib/python/Products/PageTemplates/PageTemplate.py
===
--- Zope/branches/2.9/lib/python/Products/PageTemplates/PageTemplate.py 
2005-12-02 15:58:14 UTC (rev 40480)
+++ Zope/branches/2.9/lib/python/Products/PageTemplates/PageTemplate.py 
2005-12-02 16:24:21 UTC (rev 40481)
@@ -131,7 +131,11 @@
 self._cook()
 if self._v_errors:
 __traceback_supplement__ = (PageTemplateTracebackSupplement, self)
-raise PTRuntimeError, 'Page Template %s has errors.' % self.id
+raise PTRuntimeError, (
+'Page Template %s has errors: %s' % (
+self.id,
+self._v_errors
+))
 return self._v_macros
 
 def pt_source_file(self):

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/lib/python/Products/PageTemplates/PageTemplate.py continue whack-a-mole'ing useless pagetemplate errors.

[Chris Withers]

Log message for revision 40482:
  continue whack-a-mole'ing useless pagetemplate errors.
  

Changed:
  U   
Zope/branches/Zope-2_8-branch/lib/python/Products/PageTemplates/PageTemplate.py

-=-
Modified: 
Zope/branches/Zope-2_8-branch/lib/python/Products/PageTemplates/PageTemplate.py
===
--- 
Zope/branches/Zope-2_8-branch/lib/python/Products/PageTemplates/PageTemplate.py 
2005-12-02 16:24:21 UTC (rev 40481)
+++ 
Zope/branches/Zope-2_8-branch/lib/python/Products/PageTemplates/PageTemplate.py 
2005-12-02 16:25:25 UTC (rev 40482)
@@ -131,7 +131,11 @@
 self._cook()
 if self._v_errors:
 __traceback_supplement__ = (PageTemplateTracebackSupplement, self)
-raise PTRuntimeError, 'Page Template %s has errors.' % self.id
+raise PTRuntimeError, (
+'Page Template %s has errors: %s' % (
+self.id,
+self._v_errors
+))
 return self._v_macros
 
 def pt_source_file(self):

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/ Made 'zopectl test' work for software homes which do not have an inplace build.

[Tres Seaver]

Log message for revision 40484:
  Made 'zopectl test' work for software homes which do not have an inplace 
build.
  
  It used to require that test.py be in $ZOPE_HOME/bin/;  now it will use
  $ZOPE_HOME as a fallback.
  
  

Changed:
  U   Zope/branches/Zope-2_8-branch/doc/CHANGES.txt
  U   Zope/branches/Zope-2_8-branch/lib/python/Zope2/Startup/zopectl.py

-=-
Modified: Zope/branches/Zope-2_8-branch/doc/CHANGES.txt
===
--- Zope/branches/Zope-2_8-branch/doc/CHANGES.txt   2005-12-02 16:35:58 UTC 
(rev 40483)
+++ Zope/branches/Zope-2_8-branch/doc/CHANGES.txt   2005-12-02 16:41:32 UTC 
(rev 40484)
@@ -58,6 +58,10 @@
 
 Other
 
+  - Made 'zopectl test' work for software homes which do not have
+an inplace build (it used to require that test.py be in
+$ZOPE_HOME/bin/;  now it will use $ZOPE_HOME as a fallback).
+
   - Improved logging of ConflictErrors. All conflict errors are
 logged at INFO, with counts of how many occurred and how many
 were resolved. Tracebacks for all conflicts are logged a DEBUG

Modified: Zope/branches/Zope-2_8-branch/lib/python/Zope2/Startup/zopectl.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/Zope2/Startup/zopectl.py   
2005-12-02 16:35:58 UTC (rev 40483)
+++ Zope/branches/Zope-2_8-branch/lib/python/Zope2/Startup/zopectl.py   
2005-12-02 16:41:32 UTC (rev 40484)
@@ -238,6 +238,8 @@
 return
 
 script = os.path.join(zope_home, 'bin', 'test.py')
+if not os.path.exists(script):
+script = os.path.join(zope_home, 'test.py') # no inplace build!
 assert os.path.exists(script)
 
 # If --libdir is not supplied, use $INSTANCE_HOME/Products

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/Zope2/Startup/zopectl.py Forward-port fix for non-installed software home from 2.8 branch.

[Tres Seaver]

Log message for revision 40486:
  Forward-port fix for non-installed software home from 2.8 branch.

Changed:
  U   Zope/branches/2.9/lib/python/Zope2/Startup/zopectl.py

-=-
Modified: Zope/branches/2.9/lib/python/Zope2/Startup/zopectl.py
===
--- Zope/branches/2.9/lib/python/Zope2/Startup/zopectl.py   2005-12-02 
16:44:46 UTC (rev 40485)
+++ Zope/branches/2.9/lib/python/Zope2/Startup/zopectl.py   2005-12-02 
16:46:27 UTC (rev 40486)
@@ -238,6 +238,8 @@
 return
 
 script = os.path.join(zope_home, 'bin', 'test.py')
+if not os.path.exists(script):
+script = os.path.join(zope_home, 'test.py') # no inplace build!
 assert os.path.exists(script)
 
 # Supply our config file by default.

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Zope2/Startup/zopectl.py Forward-port fix for non-installed software home from 2.8 branch.

[Tres Seaver]

Log message for revision 40488:
  Forward-port fix for non-installed software home from 2.8 branch.

Changed:
  U   Zope/trunk/lib/python/Zope2/Startup/zopectl.py

-=-
Modified: Zope/trunk/lib/python/Zope2/Startup/zopectl.py
===
--- Zope/trunk/lib/python/Zope2/Startup/zopectl.py  2005-12-02 16:46:40 UTC 
(rev 40487)
+++ Zope/trunk/lib/python/Zope2/Startup/zopectl.py  2005-12-02 16:47:12 UTC 
(rev 40488)
@@ -238,6 +238,8 @@
 return
 
 script = os.path.join(zope_home, 'bin', 'test.py')
+if not os.path.exists(script):
+script = os.path.join(zope_home, 'test.py') # no inplace build!
 assert os.path.exists(script)
 
 # Supply our config file by default.

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PythonScripts/module_access_examples.py Removed some unused imports.

[Paul Winkler]

Log message for revision 40494:
  Removed some unused imports. 
  

Changed:
  U   Zope/trunk/lib/python/Products/PythonScripts/module_access_examples.py

-=-
Modified: Zope/trunk/lib/python/Products/PythonScripts/module_access_examples.py
===
--- Zope/trunk/lib/python/Products/PythonScripts/module_access_examples.py  
2005-12-02 17:30:34 UTC (rev 40493)
+++ Zope/trunk/lib/python/Products/PythonScripts/module_access_examples.py  
2005-12-02 17:42:58 UTC (rev 40494)
@@ -33,8 +33,7 @@
 '''
 
 from AccessControl import allow_module, allow_class, allow_type
-from AccessControl import ModuleSecurityInfo, ClassSecurityInfo
-from Globals import InitializeClass
+from AccessControl import ModuleSecurityInfo
 
 
 # These modules are pretty safe

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

Re: [Zope-dev] Logging of ConflictError

[Chris Withers]

Hi Florent,

Damn, I was working on this at the same time :-S

Florent Guillaume wrote:

I've improved the logging of ConflictError in Zope 2.9 and trunk.

http://svn.zope.org/?rev=40454view=rev

Now you'll get two things:
- logs at level BLATHER for each conflict, but it may be retried
- log at level ERROR when the conflict can't be retried anymore and is 
returned to the browser as an error.


In my work, I've actually changed this to use the new, proper logging 
calls. I'll be comitting later this morning.


I removed the log at level INFO because it is very misleading for system 
administrators in my experience.


I don't think so, I've actually changed and enhanced this in my work. 
You now get a log at INFO whenever a conflict occurs. It includes more 
information than the old version, as you'll see...


Do people want this also for 2.8? Note that it changes the log format, 
so may break third party tools that parse logs.


I was planning on rolling my changes out to 2.8, 2.9 and the trunk. 
Unless anyone strenuously objects, I still intend to do that. I cleaned 
up a lot of the code and made a few other changes that generally improve 
logging.


It's a shame Florent and I were genuinely working on this at the same 
time without the other knowing...


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope-Dev maillist  -  Zope-Dev@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 )

[Zope-dev] Zope tests: 8 OK

[Zope tests summarizer]

Summary of messages to the zope-tests list.
Period Thu Dec  1 12:01:02 2005 UTC to Fri Dec  2 12:01:02 2005 UTC.
There were 8 messages: 8 from Zope Unit Tests.


Tests passed OK
---

Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux
From: Zope Unit Tests
Date: Thu Dec  1 22:15:43 EST 2005
URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003690.html

Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux
From: Zope Unit Tests
Date: Thu Dec  1 22:17:13 EST 2005
URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003691.html

Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux
From: Zope Unit Tests
Date: Thu Dec  1 22:18:44 EST 2005
URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003692.html

Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Thu Dec  1 22:20:14 EST 2005
URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003693.html

Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux
From: Zope Unit Tests
Date: Thu Dec  1 22:21:44 EST 2005
URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003694.html

Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Thu Dec  1 22:23:14 EST 2005
URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003695.html

Subject: OK : Zope-2_9-branch Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Thu Dec  1 22:24:44 EST 2005
URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003696.html

Subject: OK : Zope-trunk Python-2.4.2 : Linux
From: Zope Unit Tests
Date: Thu Dec  1 22:26:14 EST 2005
URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003697.html

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Florent Guillaume]

On 2 Dec 2005, at 11:09, Chris Withers wrote:

Damn, I was working on this at the same time :-S

Florent Guillaume wrote:

I've improved the logging of ConflictError in Zope 2.9 and trunk.
http://svn.zope.org/?rev=40454view=rev
Now you'll get two things:
- logs at level BLATHER for each conflict, but it may be retried
- log at level ERROR when the conflict can't be retried anymore  
and is returned to the browser as an error.


In my work, I've actually changed this to use the new, proper  
logging calls. I'll be comitting later this morning.


It doesn't really matter, zLOG has a compatibility layer that ends up  
doing the same thing.


I removed the log at level INFO because it is very misleading for  
system administrators in my experience.


I don't think so, I've actually changed and enhanced this in my  
work. You now get a log at INFO whenever a conflict occurs. It  
includes more information than the old version, as you'll see...


Please no. Don't put anything at INFO. A conflict error is either  
something normal that should be at level BLATHER or below, or an  
ERROR that a sysadmin wants to see logged as such. INFO sucks for  
recurring stuff like that that in addition contain the word error  
which it isn't. I can't count the number of sysadmin/customers/ 
hosting providers that freak out when something like that appears in  
the log and call us and we have to explain that yes, it's not logical  
but...


Do people want this also for 2.8? Note that it changes the log  
format, so may break third party tools that parse logs.


I was planning on rolling my changes out to 2.8, 2.9 and the trunk.  
Unless anyone strenuously objects, I still intend to do that. I  
cleaned up a lot of the code and made a few other changes that  
generally improve logging.


It's a shame Florent and I were genuinely working on this at the  
same time without the other knowing...


Well, I told you on the list that I was already working on this. You  
didn't pay attention I guess.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]



___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Florent Guillaume]

On 2 Dec 2005, at 11:09, Chris Withers wrote:
I was planning on rolling my changes out to 2.8, 2.9 and the trunk.  
Unless anyone strenuously objects, I still intend to do that. I  
cleaned up a lot of the code and made a few other changes that  
generally improve logging.


I strenuously object to you overwriting without consultation code I  
just checked in and that was approved by at least 3 people.


And I'm totally -1 on any logging at level INFO or above about  
retriable conflict errors.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]



___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Chris Withers]

Florent Guillaume wrote:
It doesn't really matter, zLOG has a compatibility layer that ends up  
doing the same thing.


python's logging module has a cleaner, nicer syntax.

Please no. Don't put anything at INFO. A conflict error is either  
something normal that should be at level BLATHER or below, or an  ERROR 
that a sysadmin wants to see logged as such. 


Not so. If I'm getting 1,000 resolved conflict errors a day, that can be 
a big performance hit, and there are those of us who have hard 
performance targets to meet ;-) Turning on debug logging is, in itself, 
a performance hit, so I don't want to have to do that on a production 
service where I want to observe the number of conflict errors occurring 
over a long period of time, like, say, a month.


INFO sucks for  recurring 
stuff like that that in addition contain the word error  which it 
isn't.


Well, that's a problem with the exception naming, and I agree with you, 
but I don't know how hard that is to change.


I can't count the number of sysadmin/customers/ hosting providers 
that freak out when something like that appears in  the log and call us 
and we have to explain that yes, it's not logical  but...


Stupid sysadmins can't be helped. It's being logged at INFO, not ERROR 
or WARNING. I agree, the exception should be renamed to just Conflict, 
but that's a totally different discussion.


Well, I told you on the list that I was already working on this. You  
didn't pay attention I guess.


You made a vague comment on the 21st Nov.
I made a definite commitment on the 24th Nov.
On the 25th, you said you were working on it in response to my question.
Now, by yesterday, 6 days later, nothing had happened, so I fixed this 
and did some other work with stupid error messages along the way.

Then, suddenly, yesterday you commit. *sigh*

Anyway, I'm going to check in the changes because they're materially the 
same but the code is cleaner.


Whether resolved conflict errors are logged at INFO or DEBUG is a 
seperate discussion and one which I'd like to see a lot more comments on 
than have been seen so far. The +1s from people yesterday were about the 
general merging of the fix to 2.8, which I would also +1 to ;-)


However, changing from INFO to DEBUG is a change in functionality which 
_I_ strenuously object to. People _need_ to be aware that they are 
seeing conflict errors, even if they are resolved. I, for one, really 
really want to be able to look in the event log and see if _any_ 
conflict errors are occurring, resolved or not, and keep track of the 
number of them so I can spot any performance hotspots before they become 
critical. FWIW, the stuff I log at INFO makes it clearer as to which 
conflicts are resolved or not, so your sysadmin types should be happier.


What do people other than Florent, whose view I think we know, feel 
about this?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Chris Withers]

Florent Guillaume wrote:
Please no. Don't put anything at INFO. A conflict error is either  
something normal that should be at level BLATHER or below, or an  ERROR 
that a sysadmin wants to see logged as such. 


Incidentally, your changes result in most users seeing two errors in 
their logs when they should just see one. I'm not aware of many serious 
users who don't copy the output of the error_log object to the event 
log, so with your changes, you'll end up with the error that ends up in 
the error_log, and your seperate LOG call's message.


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Jens Vagelpohl]

On 2 Dec 2005, at 14:16, Chris Withers wrote:
Please no. Don't put anything at INFO. A conflict error is either   
something normal that should be at level BLATHER or below, or an   
ERROR that a sysadmin wants to see logged as such.


Not so. If I'm getting 1,000 resolved conflict errors a day, that  
can be a big performance hit, and there are those of us who have  
hard performance targets to meet ;-) Turning on debug logging is,  
in itself, a performance hit, so I don't want to have to do that on  
a production service where I want to observe the number of conflict  
errors occurring over a long period of time, like, say, a month.


I agree with this argumentation. It is true that conflicts are a  
normal part of operation, as we all like to tell people who are  
scared/confused by them, but if you see so many that it bothers you  
seeing it at INFO level you know you have a problem that needs fixing.


Same is true for the panicking sysadmins that call up the developers.  
If they call because of that they should have gotten better training  
before starting to admin Zope setups, or they shouldn't be doing it  
at all.


jens

___
Zope-Dev maillist  -  Zope-Dev@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 )

[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot

[buildbot]

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot.

Buildbot URL: http://buildbot.zope.org/

Build Reason: changes
Build Source Stamp: 1919
Blamelist: chrisw,ctheune

BUILD FAILED: failed test

sincerely,
 -The Buildbot

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot

[Chris Withers]

What test failed here?

Chris

[EMAIL PROTECTED] wrote:

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot.

Buildbot URL: http://buildbot.zope.org/

Build Reason: changes
Build Source Stamp: 1919
Blamelist: chrisw,ctheune

BUILD FAILED: failed test

sincerely,
 -The Buildbot

___
Zope-Dev maillist  -  Zope-Dev@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 )



--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@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 )

[Zope-dev] Re: Logging of ConflictError

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Florent Guillaume wrote:
 On 2 Dec 2005, at 11:09, Chris Withers wrote:
 
 I was planning on rolling my changes out to 2.8, 2.9 and the trunk. 
 Unless anyone strenuously objects, I still intend to do that. I 
 cleaned up a lot of the code and made a few other changes that 
 generally improve logging.
 
 
 I strenuously object to you overwriting without consultation code I 
 just checked in and that was approved by at least 3 people.
 
 And I'm totally -1 on any logging at level INFO or above about 
 retriable conflict errors.

Likewise -1.  A successfully retried conflict should not clutter up the log.

In another message, Chris wrote:

 Not so. If I'm getting 1,000 resolved conflict errors a day, that can
 be a big performance hit, and there are those of us who have hard
 performance targets to meet ;-) Turning on debug logging is, in itself,
 a performance hit, so I don't want to have to do that on a production
 service where I want to observe the number of conflict errors occurring
 over a long period of time, like, say, a month.

You need to plan to set up and *additional* logging handler for this,
which logs *only* conflict errors at *whatever* level, rather than
requiring everybody else to live with output they don't need or want to
see.  I figured out how to do this once, long ago, to surface some
obscure BLATHER-level notification;  given your familiarity with the
logging module, it should be a snap for you. ;)


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDkF3j+gerLs4ltQ4RAsLtAJ90STWiXGtO77wMZJ7c0Y7R8a22yQCeIW9/
7Qe7tteducXydAGO54RpkJg=
=u8L+
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@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 )

[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot

[buildbot]

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot.

Buildbot URL: http://buildbot.zope.org/

Build Reason: changes
Build Source Stamp: 1921
Blamelist: chrisw

BUILD FAILED: failed test

sincerely,
 -The Buildbot

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Re: Python2.4 Security Audit ETA???

[Jim Fulton]

Christian Theune wrote:

Hi,

Am Mittwoch, den 30.11.2005, 15:52 +0100 schrieb Philipp von
Weitershausen:


Andreas Jung wrote:


Let's say it this way: it's safer than with Zope 2.8.3 but it is still not
supported :-)



From where I'm standing, with Zope 2.8.4 it's as safe as with Zope 2.9

(which actually *requires* Python 2.4...) So it is really just a label
we put on the 2.8 and 2.9 branches, in terms of the relevant code base
they're the same...



Statements like that are *dangerous*. The label is all that it is about.
It is against the possibility that although the likely relevant code
base is the same, there might be some minor minor minor switch that
makes everything burn.


I really can't figure out what your saying.


There are _several_ major linux distributions out there that already
ignore this label and shipped Zope with Python 2.4.  It's not helpful to
argue them out of that if we don't care for the label ourselves.


Python 2.4 is not supported for current production Zopes.  This
has been clearly stated for some time.  We can't prevent people
from ignoring this and creating Zope distributions based on an
unsupported Python.  People who release Zope for unsupported Python
releases are doing their users a disservice.  In this case, there
was a reasonably serious security problem introduced by Python 2.4.

What Andreas is saying is that Python 2.4 still isn't supported
for Zope 2.8.  This is different from a statement about a security
audit.  The security audit evaluated and addressed issues arising
from a change from Python 2.3 to python 2.4.  Zope 2.8.4 reflects
this.  We still choose not to support Python 2.4 for Zope 2.8 because
there hasn't been any sort of test release cycle for Zope 2.8 with
Python 2.4.  Zope 2.9 will go through such a cycle which will give us
at least some consequence.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot

[Chris Withers]

[EMAIL PROTECTED] wrote:

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot.

Buildbot URL: http://buildbot.zope.org/

Build Reason: changes
Build Source Stamp: 1921
Blamelist: chrisw

BUILD FAILED: failed test


OK, I think I got it, I guess we'll see...

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Re: Python2.4 Security Audit ETA???

[Christian Theune]

Hi,

Am Freitag, den 02.12.2005, 10:03 -0500 schrieb Jim Fulton:
 Christian Theune wrote:
  Am Mittwoch, den 30.11.2005, 15:52 +0100 schrieb Philipp von
  Weitershausen:
 From where I'm standing, with Zope 2.8.4 it's as safe as with Zope 2.9
 (which actually *requires* Python 2.4...) So it is really just a label
 we put on the 2.8 and 2.9 branches, in terms of the relevant code base
 they're the same...
  
  
  Statements like that are *dangerous*. The label is all that it is about.
  It is against the possibility that although the likely relevant code
  base is the same, there might be some minor minor minor switch that
  makes everything burn.
 
 I really can't figure out what your saying.

Sorry. See my response a couple of lines downwards.

 What Andreas is saying is that Python 2.4 still isn't supported
 for Zope 2.8.  This is different from a statement about a security
 audit.  The security audit evaluated and addressed issues arising
 from a change from Python 2.3 to python 2.4.  Zope 2.8.4 reflects
 this.  We still choose not to support Python 2.4 for Zope 2.8 because
 there hasn't been any sort of test release cycle for Zope 2.8 with
 Python 2.4.  Zope 2.9 will go through such a cycle which will give us
 at least some consequence.

If I didn't miss anything, neither an audit has happend for Zope 2.8
with Python 2.4, nor did we make it a supported platform.

IMHO it is dangerous to call it just a label that we apply. If the
audit was performed, then I'll shut up immediately. I just think that it
can happen more easily that someone picks up that's *just* a label and
will ignore recommendations in the future. 

If that happens those ignoring the recommendations can of course not
blame us, but it creates more trouble than necessary.

Just my 0.02 EUR ...

Christian

-- 
gocept gmbh  co. kg - schalaunische str. 6 - 06366 koethen - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 -
fax +49 3496 30 99 118 - zope and plone consulting and development


signature.asc
Description: This is a digitally signed message part
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Re: Logging of ConflictError

[Chris McDonough]

I initially gave Florent's proposal a +1 because frankly I'm kinda  
sick of answering people's questions about conflict errors (this  
deserves some treatment in docs actually).  But I do agree that it is  
useful to be able to see conflict errors in non-blather logs when you  
*do* know what they mean; I was just going to patch Zope myself  
locally to be able to see them after Florent applied his for the  
masses patch.


If other people like Chris feel strongly about displaying them, I'm  
not going to complain much.  Sometimes it's useful for people who  
*don't* know what they mean to see them so that when their myisam  
tables have three copies of a row or their mailhost is sending two  
emails instead of one, that we can ask them to go look at their logs  
and search for a conflict error.  The answer is always the same.. use  
a transactional doodad, but it's useful to be able to get there  
with them.


IOW, either way is fine by me.

On Dec 2, 2005, at 10:09 AM, Chris Withers wrote:


Tres Seaver wrote:
I strenuously object to you overwriting without consultation code  
I just checked in and that was approved by at least 3 people.


And I'm totally -1 on any logging at level INFO or above about  
retriable conflict errors.
Likewise -1.  A successfully retried conflict should not clutter  
up the log.


Huh? How is it cluttering up the log? At INFO level, I assert that  
if you see enough of these to judge them clutter, you really  
ought to have a look at where they're coming from and solve the  
performance problem they'll be causing...


Not so. If I'm getting 1,000 resolved conflict errors a day, that  
can

be a big performance hit, and there are those of us who have hard
performance targets to meet ;-) Turning on debug logging is, in  
itself,
a performance hit, so I don't want to have to do that on a  
production
service where I want to observe the number of conflict errors  
occurring

over a long period of time, like, say, a month.

You need to plan to set up and *additional* logging handler for this,


OK, first point, Florent's change was one that changed existing  
functionality that I, for one, was relying on. Should that really  
be happening on the 2.8 branch at the very least?



which logs *only* conflict errors at *whatever* level, rather than
requiring everybody else to live with output they don't need or  
want to

see.


I still assert that the belief it is information you shouldn't want  
to see is incorrect.



I figured out how to do this once, long ago, to surface some
obscure BLATHER-level notification;  given your familiarity with the
logging module, it should be a snap for you. ;)


Yes, unfortunately it's this familiarity that means I can point out  
the problem. At some point in 2.8's development, someone made the  
bright idea of having the event log be the root python logger.  
While I liked this in theory, in practice it means you can't set up  
seperate logs in the way you describe, since everything ends up  
getting fired at the event log anyway :-(


Then there's the issue that zope.conf doesn't support the  
configuration of additional loggers, when it really should ;-)


I'm happy to try and find time to work on the latter issue, if  
whoever made the change that resulted in the former 'fesses up and  
explains why the change was made.


In either case, I don't think it's fair to require this problem be  
solved in order for necessary conflict error logging to be resumed :-(


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@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 )



___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot

[Gary Poster]

On Dec 2, 2005, at 9:49 AM, Chris Withers wrote:


What test failed here?


Go to ...


[EMAIL PROTECTED] wrote:
The Buildbot has detected a failed build of Zope trunk 2.4 Linux  
zc-buildbot.


This url:


Buildbot URL: http://buildbot.zope.org/


Click on the 'log' link for the failed test.  In this particular case  
you would have gone to
http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/ 
builds/86/test/0


(I saw you think you fixed it, and I see that buildbot is now testing  
the changes, but you didn't say that you figured out the answer to  
your question)


Gary
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Re: Python2.4 Security Audit ETA???

[Jim Fulton]

Christian Theune wrote:

Hi,

Am Freitag, den 02.12.2005, 10:03 -0500 schrieb Jim Fulton:


Christian Theune wrote:


Am Mittwoch, den 30.11.2005, 15:52 +0100 schrieb Philipp von
Weitershausen:


From where I'm standing, with Zope 2.8.4 it's as safe as with Zope 2.9

(which actually *requires* Python 2.4...) So it is really just a label
we put on the 2.8 and 2.9 branches, in terms of the relevant code base
they're the same...



Statements like that are *dangerous*. The label is all that it is about.
It is against the possibility that although the likely relevant code
base is the same, there might be some minor minor minor switch that
makes everything burn.


I really can't figure out what your saying.



Sorry. See my response a couple of lines downwards.



What Andreas is saying is that Python 2.4 still isn't supported
for Zope 2.8.  This is different from a statement about a security
audit.  The security audit evaluated and addressed issues arising
from a change from Python 2.3 to python 2.4.  Zope 2.8.4 reflects
this.  We still choose not to support Python 2.4 for Zope 2.8 because
there hasn't been any sort of test release cycle for Zope 2.8 with
Python 2.4.  Zope 2.9 will go through such a cycle which will give us
at least some consequence.



If I didn't miss anything, neither an audit has happend for Zope 2.8
with Python 2.4, nor did we make it a supported platform.


You did miss something. As has been pointed out several times in this
thread, the audit did happen for 2.8 and 2.8.  And, as has also been
said many times, Python 2.4 with Zope 2.8 is not supported.


IMHO it is dangerous to call it just a label that we apply.


I really don't know what it you are refering to.  We did do the security
audit. We still aren't supporting Python 2.4 for Zope 2.8.

 If the

audit was performed, then I'll shut up immediately.


Cool. :)

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot

[Chris Withers]

Gary Poster wrote:


This url:


Buildbot URL: http://buildbot.zope.org/


Yup, got this now, so when you see buildbot failures, go here :-)

cheers,

Chris - who's finally starting ot understand what buildbot does!

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@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 )

[Zope-dev] RFC: _verifyObjectPaste cleanup

[yuppie]

Hi!


Basically I'd like to remove the workaround introduced to fix 
http://www.zope.org/Collectors/Zope/78 :


http://svn.zope.org/Zope/trunk/lib/python/OFS/CopySupport.py?view=diffr1=24022r2=24021

checkPermission now respects proxy roles, so this workaround is no 
longer needed.



Replacing the workaround by a checkPermission call will make the 
'permission' key in all_meta_types required, the 'action' key becomes 
optional.


The old code did have a fallback for meta_types without 'permission' 
key. This is the comment for the fallback:


  #   XXX: Ancient cruft, left here in true co-dependent fashion
  #to keep from breaking old products which don't put
  #permissions on their metadata registry entries.


Is it save to make the 'permission' key required? Or do we need the 
fallback for 'ancient cruft'? There might be new products that don't set 
the 'permission' key because it wasn't enforced until now.


I propose to

- leave Zope 2.7 untouched

- use checkPermission in Zope 2.8 and add the fallback with deprecation 
warning


- make the 'permission' key required in Zope 2.9 and later


Any comments?

Cheers,

Yuppie


___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Paul Winkler]

On Fri, Dec 02, 2005 at 02:09:56PM +0100, Florent Guillaume wrote:
 On 2 Dec 2005, at 11:09, Chris Withers wrote:
 I was planning on rolling my changes out to 2.8, 2.9 and the trunk.  
 Unless anyone strenuously objects, I still intend to do that. I  
 cleaned up a lot of the code and made a few other changes that  
 generally improve logging.
 
 I strenuously object to you overwriting without consultation code I  
 just checked in and that was approved by at least 3 people.

I'm +1 on having failed retries show up at level ERROR.

I'm neutral on having successful retries show up at level INFO, BLATHER,
or in some other log handler entirely.  Conflict errors are a pretty
small part of my world and I don't really have a strong opinion on this
part of the debate, and I don't have time to review either of
your patches.

-- 

Paul Winkler
http://www.slinkp.com
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Re: Logging of ConflictError

[Sidnei da Silva]

On Fri, Dec 02, 2005 at 03:09:40PM +, Chris Withers wrote:
| Then there's the issue that zope.conf doesn't support the configuration 
| of additional loggers, when it really should ;-)
| 
| I'm happy to try and find time to work on the latter issue, if whoever 
| made the change that resulted in the former 'fesses up and explains why 
| the change was made.

I was looking at the same issue yesterday, and it's really a trivial
change. Need to add a 'multisection' to zopeschema.xml that allows
multiple 'logger' type entries. Then you can just do something like:

logger this.that.the_other
  level BLATHER
  propagate 0 # if you don't want it to end up in error.log
  logfile
level BLATHER
path $INSTANCE/log/theother.log
  /logfile
/logger

I haven't gotten around to make the proposal for change, but since you
did, here's my 2 cents.

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com
___
Zope-Dev maillist  -  Zope-Dev@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 )

[Zope-dev] toplevel products folder in zope svn ?

[Rocky Burt]

Anyone know if there is any plan to add a toplevel products folder in
the zope svn repo like there currently is in zope's cvs repo?  I know
this has held up a few products from going from zope CVS to SVN.

- Rocky


-- 
Rocky Burt
ServerZen Software -- http://www.serverzen.com
ServerZen Hosting -- http://www.serverzenhosting.net
News About The Server -- http://www.serverzen.net

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] RFC: _verifyObjectPaste cleanup

[Dieter Maurer]

yuppie wrote at 2005-12-2 16:50 +0100:
 ...
checkPermission now respects proxy roles, so this workaround is no 
longer needed.

But we should also have some way to check permissions without proxy roles:

   It sometimes is useful for something with a proxy role
   to check whether the user (without a proxy) could
   perform the operation as well.

Thus, if checkPermission changed its behaviour, it probably
should get an optional parameter to get the old behaviour back.


Otherwise, I am happy with your cleanup.


-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Dieter Maurer]

Florent Guillaume wrote at 2005-12-1 19:49 +0100:
I've improved the logging of ConflictError in Zope 2.9 and trunk.

http://svn.zope.org/?rev=40454view=rev

Now you'll get two things:
- logs at level BLATHER for each conflict, but it may be retried
- log at level ERROR when the conflict can't be retried anymore and is 
returned to the browser as an error.

Apparently, you stopped following our thread (you, Chris, me):

  In my view, a ConflictError observed by the user
  should be treated exactly like any other exception observed by the user:
  it should go through the error_log and standard_error_message.
  It might be logged (when the user decides that exceptions seen
  by the user should be logged).

  The approach to achieve this it to fix a bug in Zope's
  zpublisher_exception_hook, not to add an explicit log
  when the final retry fails (though the extra log entry
  will not hurt significantly).


-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] KeyError: 'URL' in HTTPRequest using zope2.7-py2.3.3

[Dieter Maurer]

Brian Watson wrote at 2005-12-1 20:55 -0500:
brian w.

Traceback (most recent call last):
  File E:\NBCJEAP\Zope\lib\python\zExceptions\ExceptionFormatter.py, line 
 157,
 in formatLine
result.extend(self.formatSupplement(supp, tb))
  File E:\NBCJEAP\Zope\lib\python\zExceptions\ExceptionFormatter.py, line 
 105,
 in formatSupplement
extra = self.formatExtraInfo(supplement)
  File E:\NBCJEAP\Zope\lib\python\zExceptions\ExceptionFormatter.py, line 
 231,
 in formatExtraInfo
extra = getInfo(1)
  File E:\NBCJEAP\Zope\lib\python\Products\PageTemplates\TALES.py, line 277, 
 i
n getInfo
 ...
  File E:\NBCJEAP\Zope\lib\python\ZPublisher\HTTPRequest.py, line 1295, in 
 __r
epr__
return %s, URL=%s % (self.__class__.__name__, self['URL'])
  File E:\NBCJEAP\Zope\lib\python\ZPublisher\HTTPRequest.py, line 1214, in 
 __g
etitem__
raise KeyError, key
KeyError: 'URL'

The request in your PageTemplate context lacks an URL.

URL is set in the HTTPRequests constructor (__init__).
If an HTTPRequest instance lacks URL this means either:

  *  the instance was created in a wrong way (contructor not called)

  *  URL was deleted after construction.


Unfortunately, the details you have provided does not allow
to say more about this problem.

-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Folderish or SimpleItem object types for structural content

[Dieter Maurer]

Martijn Jacobs wrote at 2005-12-1 01:06 +0100:
 ...
If some conflict errors occure or for some reason the 
objects are not indexed (correctly) or not updated, some important 
information is not available for the user. I have experienced alot of 
problems with unindexed objects, or not reindexed objects due to 
'random' conflict errors'.

If random conflict errors lead to inconsistencies (object modified
but not reindexed), then they are very badly handled:

  Any exception that bubbles up to ZPublisher
  causes the complete transaction to be aborted: the effect will
  be neither an object modification nor a reindexing.

  If the object is modified but not reindexed in the context
  of a ConflictError, then something must have caught
  the ConflictError -- a very bad thing...

  Unfortunately, unrestricted try: ... except: ... is not
  too uncommon. Zope some problems in this respect but
  meanwhile almost all places have been cleaned up.
  
But usually, when an object is modified but not reindexed,
it is the application (and not a ConflictError)
that made the error -- it often forgets to call the reindex.

 By making a complete hierarchical structure 
using 'Object Managers', you can always assure that data is accessible, 
and if the ZCatalog is not up to date, only the search results will not 
represent the actual structure.

A much more important reason for this structure is acquisition (which
you will loose when you follow my proposal).

30.000 is not yet very impressing.
  

That's good to know. It's hard to say offcourse, but what is in some way 
a 'limit' of the number of objects, for instance, if they all have to be 
indexed? Indexing objects uses ALOT of CPU time for example... In which 
amount of objects should you reconsider your design? (Speaking of a 
'general' guideline)

Usually, you index incrementally (one object at a time).
The data structures involved when indexing a single object
behave logarithmically in the total number of objects.

Thus, I am not worried to have lots of objects indexed in the catalog.

-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Dieter Maurer]

Florent Guillaume wrote at 2005-12-2 13:33 +0100:
 ...
Please no. Don't put anything at INFO. A conflict error is either  
something normal that should be at level BLATHER or below, or an  
ERROR that a sysadmin wants to see logged as such.

I strongly disagree with you:

  ConflictErrors are essential hints that your system might
  come into trouble (they can turn into real error).

  These hints are at least as important as e.g.

2005-12-02T07:17:59 INFO ZODB.Mount Opening database for mounting: 
'144160968_1010482273.050062'
--
2005-12-02T07:17:59 INFO ZODB.Mount Mounted database 
'144160968_1010482273.050062' at /temp_folder

  Looks like INFO is a better level than BLATHER...

-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Florent Guillaume]

On 2 Dec 2005, at 20:40, Dieter Maurer wrote:

Florent Guillaume wrote at 2005-12-1 19:49 +0100:

I've improved the logging of ConflictError in Zope 2.9 and trunk.

http://svn.zope.org/?rev=40454view=rev

Now you'll get two things:
- logs at level BLATHER for each conflict, but it may be retried
- log at level ERROR when the conflict can't be retried anymore  
and is

returned to the browser as an error.


Apparently, you stopped following our thread (you, Chris, me):

  In my view, a ConflictError observed by the user
  should be treated exactly like any other exception observed by  
the user:

  it should go through the error_log and standard_error_message.


That's what my patch did.


  It might be logged (when the user decides that exceptions seen
  by the user should be logged).


I can agree with that.


  The approach to achieve this it to fix a bug in Zope's
  zpublisher_exception_hook, not to add an explicit log
  when the final retry fails (though the extra log entry
  will not hurt significantly).


The patch I did included the fix you proposed in the patch in the  
mailing list archives based on the collector entry.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]



___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Florent Guillaume]

On 2 Dec 2005, at 20:50, Dieter Maurer wrote:


Florent Guillaume wrote at 2005-12-2 13:33 +0100:

...
Please no. Don't put anything at INFO. A conflict error is either
something normal that should be at level BLATHER or below, or an
ERROR that a sysadmin wants to see logged as such.


I strongly disagree with you:

  ConflictErrors are essential hints that your system might
  come into trouble (they can turn into real error).

  These hints are at least as important as e.g.

2005-12-02T07:17:59 INFO ZODB.Mount Opening database for mounting:  
'144160968_1010482273.050062'

--
2005-12-02T07:17:59 INFO ZODB.Mount Mounted database  
'144160968_1010482273.050062' at /temp_folder


  Looks like INFO is a better level than BLATHER...



If you look at the way their purpose is explained in zLOG, you'll see  
that level INFO is reserved for things like server startup and  
shutdown. Or, as shown above, initial mounting of databases. Anything  
recurring that can happen many times in the life of the server but  
does not pose any problems should *not* be visible at INFO.


On the other hand, that's exactly what BLATHER is for folks! Use it!  
Note that it's another reason for not using the default python  
loggers who have a stupidly small number of levels.


If you want to audit your server status to see if there are changes  
real errors will happen, INFO is *not* the level to use.


Anyway, there's sufficient disagreement here, I'll send another mail  
to ask for people's votes.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]



___
Zope-Dev maillist  -  Zope-Dev@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 )

[Zope-dev] Please vote about conflict errors logging

[Florent Guillaume]

Please vote for the level at which you want to log retried conflict  
errors. These are the ConflictErrors that aren't returned to the user  
but automatically retried by the Zope publisher.


1. Do you want these ConflictErrors retried logs to be at level:
- INFO
- BLATHER
- DEBUG
- not logged
- other

2. In addition, please specify if you feel those retried  
ConflictErrors should have their full traceback logged?

- Yes, with traceback
- No, without traceback

3. Finally, please tell us if the ConflictErrors that *can't* be  
retried (and are returned to the user as an error, and are also  
logged to the error_log) should be additionally explicitely logged to  
the event log, and at which level:

- ERROR
- not logged
- other

(Also, if you feel the logging should be different between 2.8 and  
2.9, please say so.)


I'll wait until Wednesday morning to collect results.

Thanks,
Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Please vote about conflict errors logging

[Jens Vagelpohl]

1. Do you want these ConflictErrors retried logs to be at level:


INFO


2. In addition, please specify if you feel those retried  
ConflictErrors should have their full traceback logged?


no traceback


3. Finally, please tell us if the ConflictErrors that *can't* be  
retried (and are returned to the user as an error, and are also  
logged to the error_log) should be additionally explicitely logged  
to the event log, and at which level:


ERROR

jens

___
Zope-Dev maillist  -  Zope-Dev@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 )

[Zope-dev] Re: Please vote about conflict errors logging

[Florent Guillaume]

Here's my own vote :)


1. Do you want these ConflictErrors retried logs to be at level:


BLATHER

2. In addition, please specify if you feel those retried  ConflictErrors 
should have their full traceback logged?


No, without traceback

3. Finally, please tell us if the ConflictErrors that *can't* be  
retried (and are returned to the user as an error, and are also  logged 
to the error_log) should be additionally explicitely logged to  the 
event log, and at which level:


ERROR

Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Please vote about conflict errors logging

[Chris McDonough]

On Dec 2, 2005, at 5:00 PM, Florent Guillaume wrote:

Please vote for the level at which you want to log retried conflict  
errors. These are the ConflictErrors that aren't returned to the  
user but automatically retried by the Zope publisher.


1. Do you want these ConflictErrors retried logs to be at level:
- INFO
- BLATHER
- DEBUG
- not logged
- other


INFO or BLATHER




2. In addition, please specify if you feel those retried  
ConflictErrors should have their full traceback logged?

- Yes, with traceback
- No, without traceback


Traceback if at BLATHER, no traceback if at INFO.



3. Finally, please tell us if the ConflictErrors that *can't* be  
retried (and are returned to the user as an error, and are also  
logged to the error_log) should be additionally explicitely logged  
to the event log, and at which level:

- ERROR
- not logged
- other


ERROR




(Also, if you feel the logging should be different between 2.8 and  
2.9, please say so.)


I'll wait until Wednesday morning to collect results.

Thanks,
Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]

___
Zope-Dev maillist  -  Zope-Dev@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 )



___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Please vote about conflict errors logging

[Dennis Allison]

1.  INFO
2.  Yes, with traceback  (necessary as these are heissenevents)
3.  ERROR
4.  don't care -- we can adapt

Thanks Florent for taking the lead on this. I think it's a great 
help.

On Fri, 2 Dec 2005, Florent Guillaume wrote:

 Please vote for the level at which you want to log retried conflict  
 errors. These are the ConflictErrors that aren't returned to the user  
 but automatically retried by the Zope publisher.
 
 1. Do you want these ConflictErrors retried logs to be at level:
 - INFO
 - BLATHER
 - DEBUG
 - not logged
 - other
 
 2. In addition, please specify if you feel those retried  
 ConflictErrors should have their full traceback logged?
 - Yes, with traceback
 - No, without traceback
 
 3. Finally, please tell us if the ConflictErrors that *can't* be  
 retried (and are returned to the user as an error, and are also  
 logged to the error_log) should be additionally explicitely logged to  
 the event log, and at which level:
 - ERROR
 - not logged
 - other
 
 (Also, if you feel the logging should be different between 2.8 and  
 2.9, please say so.)
 
 I'll wait until Wednesday morning to collect results.
 
 Thanks,
 Florent
 
 

-- 

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Please vote about conflict errors logging

[Jean-Marc Orliaguet]

Florent Guillaume wrote:

Please vote for the level at which you want to log retried conflict  
errors. These are the ConflictErrors that aren't returned to the user  
but automatically retried by the Zope publisher.


1. Do you want these ConflictErrors retried logs to be at level:
- INFO
- BLATHER
- DEBUG
- not logged
- other

BLATHER (I have never be able to get any meaningful information from 
them, except that zope tries several times)


2. In addition, please specify if you feel those retried  
ConflictErrors should have their full traceback logged?

- Yes, with traceback
- No, without traceback



Full traceback, since we're in BLATHER mode

3. Finally, please tell us if the ConflictErrors that *can't* be  
retried (and are returned to the user as an error, and are also  
logged to the error_log) should be additionally explicitely logged to  
the event log, and at which level:

- ERROR
- not logged
- other


ERROR

/JM

(Also, if you feel the logging should be different between 2.8 and  
2.9, please say so.)


I'll wait until Wednesday morning to collect results.

Thanks,
Florent



___
Zope-Dev maillist  -  Zope-Dev@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 )

[Zope-dev] Re: Please vote about conflict errors logging

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Florent Guillaume wrote:
 Please vote for the level at which you want to log retried conflict 
 errors. These are the ConflictErrors that aren't returned to the user 
 but automatically retried by the Zope publisher.
 
 1. Do you want these ConflictErrors retried logs to be at level:
 - INFO
 - BLATHER
 - DEBUG
 - not logged
 - other

BLATHER

 2. In addition, please specify if you feel those retried  ConflictErrors
 should have their full traceback logged?
 - Yes, with traceback
 - No, without traceback

Yes, with traceback

 3. Finally, please tell us if the ConflictErrors that *can't* be 
 retried (and are returned to the user as an error, and are also  logged
 to the error_log) should be additionally explicitely logged to  the
 event log, and at which level:
 - ERROR
 - not logged
 - other

ERROR

 (Also, if you feel the logging should be different between 2.8 and  2.9,
 please say so.)

Make it the same.


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDkQ+++gerLs4ltQ4RAhDrAJ9pjTXb9F6bEoZGQ1xTA2lyI47knQCgiXWK
8blEg0KiwVIIKlt95gK9CPg=
=JUyS
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Logging of ConflictError

[Chris Withers]

Paul Winkler wrote:


I'm +1 on having failed retries show up at level ERROR.


With Florent's changes you get 'em twice, with mine, you get 'em once ;-)


I'm neutral on having successful retries show up at level INFO, BLATHER,
or in some other log handler entirely.  Conflict errors are a pretty
small part of my world and I don't really have a strong opinion on this
part of the debate, and I don't have time to review either of
your patches.


Well, if you ever run into performance problems, you might care about 
them...


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Re: Logging of ConflictError

[Chris Withers]

Sidnei da Silva wrote:

I was looking at the same issue yesterday, and it's really a trivial
change. Need to add a 'multisection' to zopeschema.xml that allows
multiple 'logger' type entries. Then you can just do something like:


Yes, that bit is simple. But in 2.8.something and above, the eventlog is 
plugged in as a root logger, meaning you can't get anything logged that 
doesn't go to it. Who made this change and why?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Please vote about conflict errors logging

[Chris Withers]

Florent Guillaume wrote:

1. Do you want these ConflictErrors retried logs to be at level:
- INFO


2. In addition, please specify if you feel those retried  ConflictErrors 
should have their full traceback logged?

- No, without traceback


The actual traceback for any conflict error is pretty useless, since it 
comes from one of very few places inside zodb


3. Finally, please tell us if the ConflictErrors that *can't* be  
retried (and are returned to the user as an error, and are also  logged 
to the error_log) should be additionally explicitely logged to  the 
event log, and at which level:

- ERROR


...ie: handled in the same way as any other user-visible error: 
standard_error_message and error_log.


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Please vote about conflict errors logging

[Chris Withers]

Jean-Marc Orliaguet wrote:
BLATHER (I have never be able to get any meaningful information from 
them, except that zope tries several times)


That's because they excluded any useful information before. The 
implementation I've put in tells you, at info level, what error actually 
occurred, what object it occurred on, how many conflicts occurred since 
server start and how many of those were resolved. It's compact and 
informative.


I'd suggest anyone who's voting for blather should actually check out 
the trunk and try the functional test I put in to see the new code in 
action...


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope-dev] Re: Logging of ConflictError

[Sidnei da Silva]

On Dec 2, 2005, at 3:51 PM, Chris Withers wrote:


Sidnei da Silva wrote:

I was looking at the same issue yesterday, and it's really a trivial
change. Need to add a 'multisection' to zopeschema.xml that allows
multiple 'logger' type entries. Then you can just do something like:


Yes, that bit is simple. But in 2.8.something and above, the eventlog 
is plugged in as a root logger, meaning you can't get anything logged 
that doesn't go to it. Who made this change and why?


Yes you can. Just set 'propagate' to a non-true value.

--
Sidnei da Silva
Enfold Systems, LLC
http://enfoldsystems.com

___
Zope-Dev maillist  -  Zope-Dev@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 )

Re: [Zope] exUserFolder will not redirect to login page

[Andrew Milton]

+---[ Gaute Amundsen ]--
| On Friday 02 December 2005 04:31, Andrew Milton wrote:
|  +---[ Gaute Amundsen ]--
| 
|  | Hi all.
|  |
|  | I have this problem with our zope based CMS system.
|  | No matter what i try I can not make the docLogin page appear when it
|  | should. If I go directly to it, it works fine, but otherwise the http
|  | auth poppup appears.
| 
|  I don't know what version of exUserFolder you're using, but, try looking in
| 
|  exUserFolder-0-10-10

On man, this is positively ancient.

Move to 0.20.x or 0.50.x and try again.

If you're already setup, I suggest moving to 0.20.x, since 0.50.x involved a
code-reshuffle, and ZODB pickles don't like that so much :-) 

-- 
Andrew Milton
[EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Python Classes and Zope.

[Chris Withers]

Dario Lopez-Kästen wrote:
Most, if not all examples, out there assume that the external 
packages/modules/classes can freely be converted to Zope-classes.


No so, all you have to do is provide security assertions for them. I 
usually do this is a dummy product's __init__.py.


See the examples in PythonScripts standard.py...

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Python Classes and Zope.

[Chris Withers]

Fernando Lujan wrote:

For instance, if I create the class:

class MyClass:
A simple example class
i = 12345
def f(self):
return 'hello world'

Can I invoke the following code inside a Python Script?

x = MyClass()
x.f()


Yes, but you shouldn't want to ;-)


I'm using zope 2.7.x series.


Why? 2.8 is much much better...

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Python Classes and Zope.

[Chris Withers]

Willi Langenberger wrote:


You could add

__allow_access_to_unprotected_subobjects__ = 1


You _could_, but that's a very old, deprecated interface. And, with the 
work Jim's talking about doing, it might actually stop working.


nowadays you should do:

security = ClassSecurityInfo()

security.setDefaultAccess('allow')

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Beginners Confusion

[Chris Withers]

Russell Winter wrote:
 
I would like to have each user having, either,  their own Zope Server

binaries (including CMF  Plone) in their home directories.


Why? What's the use case here?

I'd install the binaries for each version of Zope once.
Plone, much as it pretends not to be, is just an add-on product.
I'd use mkzopeinstance for each user, put the instance in their home 
directory and put any additional software such as Plone in the Poducts 
directory of the instance...


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] How to Update files that are already uploaded

[Chris Withers]

Jonathan wrote:
File objects have a method called 'update_data' which may be of use. 


I'd suggest manage_upload instead...

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] exUserFolder will not redirect to login page

[Chris Withers]

Gaute Amundsen wrote:


As far as I can see that must mean that either something is going wrong in 
exUserFolder, or much more likely, that we are feeding it something bogus, or 
have previously modified it in some non-obvious way.
My problem is that I have little idea what it is supposed to look like at 
different stages.


You could always use SimpleUserFolder and CookieCrumbler ;-)

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] exUserFolder will not redirect to login page

[Gaute Amundsen]

|  I don't know what version of exUserFolder you're using, but, try looking 
in
| 
|  exUserFolder-0-10-10

On man, this is positively ancient.

Move to 0.20.x or 0.50.x and try again.

If you're already setup, I suggest moving to 0.20.x, since 0.50.x involved a
code-reshuffle, and ZODB pickles don't like that so much :-)

Sorry about that. 
Thought I had checked that, but I must have mixed it up with MysqlUserFolder, 
which setup alerted me to this whole mess.

Will try an upgrade, but since MysqlUserFolder displays the same problem I 
suspect I will be back shortly :-/

G.
-- 
-- -
  Gaute Amundsen   Technology today is the campfire
  [EMAIL PROTECTED]   around which we tell our stories.
  There's this attraction to light
  and to this kind of power, which is
   both warm and destructive.

   Laurie Anderson
 http://www.div.org

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] exUserFolder will not redirect to login page

[Gaute Amundsen]

On Friday 02 December 2005 10:45, Chris Withers wrote:
 Gaute Amundsen wrote:
  As far as I can see that must mean that either something is going wrong
  in exUserFolder, or much more likely, that we are feeding it something
  bogus, or have previously modified it in some non-obvious way.
  My problem is that I have little idea what it is supposed to look like at
  different stages.

 You could always use SimpleUserFolder and CookieCrumbler ;-)


Good idea.
Will give it a try. 
Even if only to try to isolate the problem.

G.
 
-- -
  Gaute Amundsen   Technology today is the campfire
  [EMAIL PROTECTED]   around which we tell our stories.
  There's this attraction to light
  and to this kind of power, which is
   both warm and destructive.

   Laurie Anderson
 http://www.div.org

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Beginners Confusion

[Lennart Regebro]

On 12/1/05, Russell Winter [EMAIL PROTECTED] wrote:
 Alternatively, as multiple Zope Servers on one machine will be quite a
 resource eater, (probably 20 main users) is it possible to have just one
 Zope Server and multiple instances of the database/CMF/Plone for the users?

Sure. Although it gets tricky if you want to have different product
versions for them.

 All user instances and content including the database entries would need to
 be accounted for in and installed in their own home directories to allow us
 to control and manage each user or groups bandwidth and quota's etc etc.

Sligthly more tricky, but still possible. Especially bandwidth can be
problematic, but if you have separate domains for each user and have
an apache-server that regulates the bandwidth per domain it should be
fine.

You would also have to mount a separate ZODB for each user.

But having one instance per user is probably eaasier.
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] checking for elements in a list

[Christopher Rivard]

Hello,

I'm am trying to check for the membership of items in a list and think 
I'm missing something.

How is this done in dtml?

List allids: [15,16,17,18]

Check for multiple items in the list:

dtml-in allids prefix=loop
dtml-if expr=loop_item == 17
something
dtml-elif expr=loop_item == 17 and loop_item != 18
doesn't work
/dtml-if
/dtml-in

The goal is to check for combinations:
17 and not 18
18 only
17 only
17 and 15
18 and 16
...combinations.

I don't think that I really want to loop through the list, just want to 
check membership in the list.



Thanks in advance,
Chris


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] checking for elements in a list

[Andreas Jung]

You should definitely move such *complex* logic into a PythonScript.
DTML is made for generating content but not to implement such
complex logic...and of course the elif part won't work because that's the 
semantic of if-elif.


-aj

--On 2. Dezember 2005 05:37:17 -0700 Christopher Rivard 
[EMAIL PROTECTED] wrote:



Hello,

I'm am trying to check for the membership of items in a list and think
I'm missing something.
How is this done in dtml?

List allids: [15,16,17,18]

Check for multiple items in the list:

dtml-in allids prefix=loop
dtml-if expr=loop_item == 17
something
dtml-elif expr=loop_item == 17 and loop_item != 18
doesn't work
/dtml-if
/dtml-in

The goal is to check for combinations:
17 and not 18
18 only
17 only
17 and 15
18 and 16
...combinations.

I don't think that I really want to loop through the list, just want to
check membership in the list.


Thanks in advance,
Chris


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -  http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )






pgp9sLSrLxqCK.pgp
Description: PGP signature
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] exUserFolder will not redirect to login page

[Andrew Milton]

+---[ Gaute Amundsen ]--
| |  I don't know what version of exUserFolder you're using, but, try looking 
| in
| | 
| |  exUserFolder-0-10-10
| 
| On man, this is positively ancient.
| 
| Move to 0.20.x or 0.50.x and try again.
| 
| If you're already setup, I suggest moving to 0.20.x, since 0.50.x involved a
| code-reshuffle, and ZODB pickles don't like that so much :-)
| 
| Sorry about that. 
| Thought I had checked that, but I must have mixed it up with MysqlUserFolder, 
| which setup alerted me to this whole mess.
| 
| Will try an upgrade, but since MysqlUserFolder displays the same problem I 
| suspect I will be back shortly :-/

Given there's two user folders giving you the same response, it's unlikely to
be the same bug in two different user folder implementations :-)

Since your index_html and docLogin both seem to require permissions to view, I
would check to make sure that your 'header' and 'footer' items aren't doing
something restricted.

If you're using DTML, then I'd check that standard_html_header and
standard_html_footer.

Make sure that in addition to the 'View' permission that also the
'Access Contents information' permissions are set for Anonymous
on headers, footers and docLogin (and index_html if required).

-- 
Andrew Milton
[EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] why will FastCGI not be supported in the Future.

[Andreas Jung]

--On 28. November 2005 16:09:31 +0100 Andreas Jung [EMAIL PROTECTED] 
wrote:




I've seen lots of heavy loaded Zope sites - I've not seen a single one
using FastCGI. Can you give us some number about the FastCGI performance
compared to the standard mod_rewrite approach? Let numbers speakBut
please read carefully...I wrote about deprecating the module but not
about removing it as in my original posting. We want o make clear that
FCGI is not supported.
You are of course free to use it as long as you need.



Effective from Zope 2.9 I marked FCGI as deprecated - both in the 
documentation and through a deprecation warning in the sources. Please note 
that it does not mean that the FCGI might go away automatically in the 
future. This is basically a reminder for people using FCGI that there is a 
better way (in our opinion) to run Zope under  Apache than using FCGI.



-aj



pgp3NCEpzd4W3.pgp
Description: PGP signature
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] why will FastCGI not be supported in the Future.

[Andrew Milton]

+---[ Andreas Jung ]--
| 
| Effective from Zope 2.9 I marked FCGI as deprecated - both in the 
| documentation and through a deprecation warning in the sources. Please note 
| that it does not mean that the FCGI might go away automatically in the 
| future. This is basically a reminder for people using FCGI that there is a 
| better way (in our opinion) to run Zope under  Apache than using FCGI.

This of course assumes the entire world runs Apache.

-- 
Andrew Milton
[EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: why will FastCGI not be supported in the Future.

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Milton wrote:
 +---[ Andreas Jung ]--
 | 
 | Effective from Zope 2.9 I marked FCGI as deprecated - both in the 
 | documentation and through a deprecation warning in the sources. Please note 
 | that it does not mean that the FCGI might go away automatically in the 
 | future. This is basically a reminder for people using FCGI that there is a 
 | better way (in our opinion) to run Zope under  Apache than using FCGI.
 
 This of course assumes the entire world runs Apache.

How big do you imagine the set is of people running Zope via FastCGI who
are *not* running Apache as the front end?  Now how big is the
intersection of that set with the set of folks who have (and will use)
commit access to Zope?

The real issue from Andreas' point of view is that *nobody* who helps
maintain Zope also knows and uses FastCGI;  *he* used to be the person
who did know it (per http://www.fastcgi.com/), but no longer.

Without such a person or persons, Zope cannot really claim to support
FastCGI at all.


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDkFtB+gerLs4ltQ4RAo2qAKDTUprNSpcaoiCglQY9brm8mp06NgCeKtkf
WeXQcLjwdtGHJs1LoOO3R60=
=SiZt
-END PGP SIGNATURE-

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Python Classes and Zope.

[Paul Winkler]

On Fri, Dec 02, 2005 at 09:38:56AM +, Chris Withers wrote:
 Dario Lopez-K?sten wrote:
 Most, if not all examples, out there assume that the external 
 packages/modules/classes can freely be converted to Zope-classes.
 
 No so, all you have to do is provide security assertions for them. I 
 usually do this is a dummy product's __init__.py.
 
 See the examples in PythonScripts standard.py...

Those are mostly to do with declaring callables (i.e. functions)
importable, by using ModuleSecurityInfo().declarePublic('foo').
Very useful, but it doesn't show how to allow scripts to
use already instantiated objects passed to a Script from
some product code.

One way is to do the following in a method of
your trusted (product) code:

1) create a derived or wrapper class that inherits from
Acquisition.Implicit or Acquisition.Explicit.
This can either inherit from your existing class,
or wrap it, as you prefer.

2) in the wrapper class, use ClassSecurityInfo() to 
declare the methods you need public or permission-protected,
or use allowAny().

3) initializeClass(myWrapper)

4) instantiate one of these and give it a security context,
e.g. myWrapperInstance = myWrapper(existing_object).__of__(self) 

5) return the wrapper



You know, some days I wonder why it is that Zope is the
only framework around that needs to distinguish between 
trusted and untrusted code. Nobody else seems to be
looking at us with envy in this regard.
Historically I know it was because there was the idea that
not-fully-trustworthy people might be able to join your site
and then add DTML to it, and you don't want such people
allowed to execute arbitrary code ... like the old zope.org
site.  But does anybody anywhere actually run a site like that
nowadays? It's kind of a bizarre idea.

-- 

Paul Winkler
http://www.slinkp.com
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Python Classes and Zope.

[Paul Winkler]

On Thu, Dec 01, 2005 at 09:04:11PM +0100, Jean-Marc Orliaguet wrote:
 You need to call InitializeClass on your object, and that's it.
 
 cf http://www.upfrontsystems.co.za/courses/zope/ch04.html
 
 under Zopifying our Python classes

initializeClass() only helps if the class you feed it
inherits from Acquisition.Implicit or Acquisition.Explicit,
and has some security declarations in it.

-- 

Paul Winkler
http://www.slinkp.com
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Python Classes and Zope.

[Chris McDonough]

On Dec 2, 2005, at 9:49 AM, Paul Winkler wrote:

You know, some days I wonder why it is that Zope is the
only framework around that needs to distinguish between
trusted and untrusted code. Nobody else seems to be
looking at us with envy in this regard.
Historically I know it was because there was the idea that
not-fully-trustworthy people might be able to join your site
and then add DTML to it, and you don't want such people
allowed to execute arbitrary code ... like the old zope.org
site.  But does anybody anywhere actually run a site like that
nowadays? It's kind of a bizarre idea.


Not really, and that's why Zope 3 has avoided through the web code  
so far.  I hope this avoidance continues at least in the core,  
whatever that is, but I see rumblings every so often about why this  
is a can't-live-without thing (with which I strongly disagree).


- C

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Python Classes and Zope.

[Jean-Marc Orliaguet]

Paul Winkler wrote:


On Thu, Dec 01, 2005 at 09:04:11PM +0100, Jean-Marc Orliaguet wrote:
 


You need to call InitializeClass on your object, and that's it.

cf http://www.upfrontsystems.co.za/courses/zope/ch04.html

under Zopifying our Python classes
   



initializeClass() only helps if the class you feed it
inherits from Acquisition.Implicit or Acquisition.Explicit,
and has some security declarations in it.

 



for protected methods, but what if your methods are public?

http://www.zope.org/Wikis/DevSite/Projects/DeclarativeSecurity/ZopeSecurityForDevelopers/wikipage_view


- It is important to note what can and cannot be protected using the 
|SecurityInfo| interface. First, the security policy relies on 
/Acquisition/ to aggregate access control information, so any class that 
needs to work in the security policy must have either 
|Acquisition.Implicit| or |Acquisition.Explicit| in its base class 
hierarchy.


- if the object has a security assertion that it is /public/ then access 
will be granted



does zope2 do an access control based on acquisition for public methods, 
that would be a waste of resources since the answer is always yes, 
granted ?


/JM


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Python Classes and Zope.

[Paul Winkler]

On Fri, Dec 02, 2005 at 04:12:01PM +0100, Jean-Marc Orliaguet wrote:
 does zope2 do an access control based on acquisition for public methods, 
 that would be a waste of resources since the answer is always yes, 
 granted ?

Well, the thing is, the declaration that makes the method public
*has no effect* unless your class participates in acquisition.

Oh, and the instance needs to be given an acquisition context, too.
e.g.  foo = foo.__of__.some_parent

-- 

Paul Winkler
http://www.slinkp.com
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Python Classes and Zope.

[Paul Winkler]

On Fri, Dec 02, 2005 at 09:49:25AM -0500, Paul Winkler wrote:
 2) in the wrapper class, use ClassSecurityInfo() to 
 declare the methods you need public or permission-protected,
 or use allowAny().

Brain fart, sorry. There is no allowAny in ClassSecurityInfo
or elsewhere.
 
The quick-and-easy thing to do, if you don't want to create
wrapper or derived class, somewhere in some Product code,
do stuff like the following:

from AccessControl import allow_class, allow_module, ModuleSecurityInfo

# Allow scripts to *instantiate* a class.
# Skip this if your scripts don't need to instantiate the objects.
# Note that you can't call methods on it yet, keep reading...

ModuleSecurityInfo('Products.MyProduct').declarePublic('myclass')

# Allow unrestricted access to all *existing* instances
# of a class. Now you can call its methods.
# Note this *doesn't* automatically allow you to use
# other objects returned by any of its methods, so 
# you may need to explicitly allow a bunch of other classes too...

allow_class(myclass)

# Allow scripts to import and use a function defined in
# some product. This works just like allowing to instantiate classes.

ModuleSecurityInfo('Products.MyProduct').declarePublic('myfunc')

# Works for standard library or other modules on $PYTHONPATH too.

ModuleSecurityInfo('urllib').declarePublic('urlopen')


# Allow unrestricted imports and usage of an *entire* module:
allow_module('mypackage.mymodule')
# ... well, mostly. Sometimes that doesn't work and you need
# to sprinkle in a few more declarations, e.g. for types
# defined in C.
# See for example
# lib/python/Products/PythonScripts/module_access_examples.py
# showing complications for e.g. the re module.

-- 


Paul Winkler
http://www.slinkp.com
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] exUserFolder will not redirect to login page

[Gaute Amundsen]

On Friday 02 December 2005 14:46, Andrew Milton wrote:
 +---[ Gaute Amundsen ]--

snip
 | Sorry about that.
 | Thought I had checked that, but I must have mixed it up with
 | MysqlUserFolder, which setup alerted me to this whole mess.
 |
 | Will try an upgrade, but since MysqlUserFolder displays the same problem
 | I suspect I will be back shortly :-/

 Given there's two user folders giving you the same response, it's unlikely
 to be the same bug in two different user folder implementations :-)

My thoughts exactly. It's worth a try anyway at this stage, but I have not had 
time for that yet.

 Since your index_html and docLogin both seem to require permissions to
 view, 
No, no, and NO again. docLogin noes NOT require permission.
I can access it without problem. If I cold not this would probably be a simple 
problem, and I would not be posting to the list.

 I would check to make sure that your 'header' and 'footer' items 
 aren't doing something restricted.

 If you're using DTML, then I'd check that standard_html_header and
 standard_html_footer.

 Make sure that in addition to the 'View' permission that also the
 'Access Contents information' permissions are set for Anonymous
 on headers, footers and docLogin (and index_html if required).

I am sorry, but I have been down that path numerous times, and it is all in 
order.

I remove 'view' permission for anonymous from a folder or index.html file way 
below acl_users, and I get the described problem when I try to access it. 
I restore that permission, and everything displays properly. 
If I go to acl_users/docLogin directly, I can log in with cookies, and 
everything works fine. I believe that neatly eliminates the concerns you 
raise here.

To be frank I really think my first post described the situation quite 
precisely. 

I do not think exUserFolder is faulty in any way, except possibly by our own 
modification, but that is what I have to work with to try to figure out what 
is going on.

I was hoping it would be a product that many would be familiar with, and that 
as such it wold be a good reference point to grapple with the more general 
principles. Noting beats assistance from the author of course,
but please don't insist on treating this as a newbee question :)


G.

-- 
-- -
  Gaute Amundsen   Technology today is the campfire
  [EMAIL PROTECTED]   around which we tell our stories.
  There's this attraction to light
  and to this kind of power, which is
   both warm and destructive.

   Laurie Anderson
 http://www.div.org

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: index_object() and bobobase_modification_time with different ZCatalogs

[Dieter Maurer]

Tres Seaver wrote at 2005-12-1 12:30 -0500:
 ...
Hmmm, I wonder if one could hack it by avoiding '__setattr__', e.g.:

   for cat in catalogs:
   object.__dict__['default_catalog'] = cat
   object.index_object()

   cat._p_deactivate() # throw away changes

You probably mean object._p_deactivate().

This will not work when object was modified before.

But why don't we avoid the whole thing and just call the catalog directly:

   for cat in catalogs:
   cat.catalog_object(object, object.url()

Usually, object will not have an url method (or attribute).
Apart from that, this is a very good idea.

An alternative could be the use of a wrapper:

   from ExtensionClass import Base

   class _Wrapper(Base):
 def __init__(cat, obj):
   self.default_catalog = cat
   self.__obj = obj

 def indexObject(self):
   self.__obj.indexObject.im_func(self)
 ... similar for the other indexing related method ...

 def __getattr__(self, key): return getattr(self.__obj, key)

-- 
Dieter
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Python Classes and Zope.

[Florent Guillaume]

Paul Winkler wrote:

On Fri, Dec 02, 2005 at 04:12:01PM +0100, Jean-Marc Orliaguet wrote:

does zope2 do an access control based on acquisition for public methods, 
that would be a waste of resources since the answer is always yes, 
granted ?



Well, the thing is, the declaration that makes the method public
*has no effect* unless your class participates in acquisition.


That's not true. The objects of this class will be perfectly accessible 
to a restricted user:


  from AccessControl import ClassSecurityInfo
  class MyStuff(object):
  security = ClassSecurityInfo()
  security.declareObjectPublic()
  security.setDefaultAccess('allow')
  def foo(self):
  return 'bar'
  InitializeClass(MyStuff)

Which also can be written more shorly an less invasively:

  class MyStuff(object):
  def foo(self):
  return 'bar'
  from AccessControl import allow_class
  allow_class(MyStuff)

allow_class does the same thing as declareObjectPublic + 
setDefaultAccess('allow')


For instance you could have in you this same code:

  from AccessControl import ModuleSecurityInfo
  ModuleSecurityInfo('Products.ThisProduct.ThisFile'
).declarePublic('getStuff')
  def getStuff():
return MyStuff()

And in restricted code you can then do:

  from Products.ThisProduct.ThisFile import getStuff
  ob = getStuff()
  v = ob.foo()


 Oh, and the instance needs to be given an acquisition context, too.
 e.g.  foo = foo.__of__.some_parent



It's only if you want to protect a method with a specific permission 
that's not public or private that you'll have to provide acquisition 
context so that Zope can find out what roles have this permission and 
match them against the current user's roles:


  class MyStuff(Acquisition.Implicit):
  security = ClassSecurityInfo()
  security.declareObjectPublic()
  security.setDefaultAccess('allow')
  def foo(self):
  return 'bar'
  security.declareProtected('View')
  def viewit(self):
  return 'yo mama'
  InitializeClass(MyStuff)
  ...
  def getStuff(context):
return MyStuff().__of__(context)

Then in restricted code you'll be able to do:

  ...
  ob = getStuff(context)
  v = ob.viewit()

Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] exUserFolder will not redirect to login page

[Andrew Milton]

+---[ Gaute Amundsen ]--
| 
|  Since your index_html and docLogin both seem to require permissions to
|  view, 
| No, no, and NO again. docLogin noes NOT require permission.
| I can access it without problem. If I cold not this would probably be a 
simple 
| problem, and I would not be posting to the list.
|
|  I would check to make sure that your 'header' and 'footer' items 
|  aren't doing something restricted.
| 
|  If you're using DTML, then I'd check that standard_html_header and
|  standard_html_footer.
| 
|  Make sure that in addition to the 'View' permission that also the
|  'Access Contents information' permissions are set for Anonymous
|  on headers, footers and docLogin (and index_html if required).
| 
| I am sorry, but I have been down that path numerous times, and it is all in 
| order.
| 
| I remove 'view' permission for anonymous from a folder or index.html file way 
| below acl_users, and I get the described problem when I try to access it. 
| I restore that permission, and everything displays properly. 
| If I go to acl_users/docLogin directly, I can log in with cookies, and 
| everything works fine. I believe that neatly eliminates the concerns you 
| raise here.

Not really d8) The primary cause for getting a Basic Auth Pop is because your
login form is attempting to do something that an Anonymous user doesn't have
permission to do. There's another acl_users between exUserFolder and the
content item (so it's getting the wrong user folder, unlikely in this case), 
or you have an item in  your page, header, or footer that is duplicated at 
a lower level that has permissions missing..

E.g /a/b/c/docLogin  works fine, but, /a/b/c/d/e/docLogin doesn't because 
something at /a/b/c/d or lower is locked for Anon users, but, isn't at /a/b/c

Does that make sense ?

| I was hoping it would be a product that many would be familiar with, and that 
| as such it wold be a good reference point to grapple with the more general 
| principles. Noting beats assistance from the author of course,
| but please don't insist on treating this as a newbee question :)

Maybe if you saw my INBOX you'd understand d8)

-- 
Andrew Milton
[EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: why will FastCGI not be supported in the Future.

[Andrew Milton]

+---[ Tres Seaver ]--
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
| 
| Andrew Milton wrote:
|  +---[ Andreas Jung ]--
|  | 
|  | Effective from Zope 2.9 I marked FCGI as deprecated - both in the 
|  | documentation and through a deprecation warning in the sources. Please 
note 
|  | that it does not mean that the FCGI might go away automatically in the 
|  | future. This is basically a reminder for people using FCGI that there is 
a 
|  | better way (in our opinion) to run Zope under  Apache than using FCGI.
|  
|  This of course assumes the entire world runs Apache.
| 
| How big do you imagine the set is of people running Zope via FastCGI who
| are *not* running Apache as the front end?  Now how big is the
| intersection of that set with the set of folks who have (and will use)
| commit access to Zope?
|
| The real issue from Andreas' point of view is that *nobody* who helps
| maintain Zope also knows and uses FastCGI;  *he* used to be the person
| who did know it (per http://www.fastcgi.com/), but no longer.
|
| Without such a person or persons, Zope cannot really claim to support
| FastCGI at all.

My issue isn't with the loss of FCGI (although I know a few hosting companies
that might be upset at that, perhaps you can scare them into funding its
maintainence d8). It's with the way that there is 'a real issue' and a
'made up justification'. 

If there's noone around who can maintain it, then just say that. Don't say
there's 'a better way', because I can guarantee you the people using FCGI are
using it for a reason, and there isn't a better way for them. 

P.S. 

I can imagine a pretty big set of people running Zope via FCGI who are
not running Apache.. I can also imagine that magical code fairies fight with
magical code trolls to the death to decide what pieces of code stay and which 
pieces go.

-- 
Andrew Milton
[EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope-DB] Z SQL equivelant of MySQL's SQL_CALC_FOUND_ROWS?

[Chris Withers]

Charlie Clark wrote:

That doesn't work if you use offsets and limits to only return part of a
result set...


SELECT count(attribute) FROM relatiin WHERE condition


Ah, okay, now I gotcha...


only returns 1 result so it's independent of LIMIT and result sets.


I wonder how the two methods compare efficiency-wise?

Of course, ZopeDAs such as our mxODBCZopeDA can be extended to support 
additional commands on the connection but that is not part of the ZSQL 
specification and will vary from RDBMS to RDBMS as the initial mail noted.


Well, that's why MySQL does it as an SQL statement, no? ;-)

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db

Re: [Zope-DB] Z SQL equivelant of MySQL's SQL_CALC_FOUND_ROWS?

[Charlie Clark]

On 2005-12-02 at 10:33:34 [+0100], Chris Withers [EMAIL PROTECTED] 
wrote:
 Charlie Clark wrote:
 That doesn't work if you use offsets and limits to only return part of a
 result set...
  
  SELECT count(attribute) FROM relatiin WHERE condition
 
 Ah, okay, now I gotcha...
 
  only returns 1 result so it's independent of LIMIT and result sets.
 
 I wonder how the two methods compare efficiency-wise?

ah, that might well be in the realms of db-tuning and magic but one might 
expect a count() operation to be slightly faster as it requires less data to 
be packaged. The implementation of LIMITs and result sets might vary 
significantly from system to system.

  Of course, ZopeDAs such as our mxODBCZopeDA can be extended to support
  additional commands on the connection but that is not part of the ZSQL
  specification and will vary from RDBMS to RDBMS as the initial mail noted.
 
 Well, that's why MySQL does it as an SQL statement, no? ;-)

Maybe although I sometimes why MySQL does anything: the documentation seems 
to imply that many decisions were sort of let's do it like this: cf. 
particularly the recommendations for writing queries with JOINs. Personally I 
do not see it as valid SQL to predicate a query on what was just asked. 

Regarding the original question: if I know I am working with LIMITs or result 
sets then this implies I don't want to know the total size of the results 
beyound len(results). Of course, it can be a right Tony Blair rewriting a 
complex SQL query just to add a count in there as opposed to calling a method 
on a cursor object. And this is where ZopeDA connections could do with 
improved support beyond the current it's good enough as it is situation so 
that database functions can be called directly more easily where required. 
But as we all know, so far no one has come forward to champion new generation 
ZSQLs and ZopeDAs to do this.

Charlie
___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db