[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/ - Collector #1976: FTP STOR command would load the file being

2005-12-16 Thread Sidnei da Silva
Log message for revision 40805:
  
- Collector #1976: FTP STOR command would load the file being
  uploaded in memory. Changed to use a TemporaryFile.
  

Changed:
  U   Zope/branches/Zope-2_8-branch/doc/CHANGES.txt
  U   Zope/branches/Zope-2_8-branch/lib/python/ZServer/FTPRequest.py
  U   Zope/branches/Zope-2_8-branch/lib/python/ZServer/FTPServer.py

-=-
Modified: Zope/branches/Zope-2_8-branch/doc/CHANGES.txt
===
--- Zope/branches/Zope-2_8-branch/doc/CHANGES.txt   2005-12-16 11:58:29 UTC 
(rev 40804)
+++ Zope/branches/Zope-2_8-branch/doc/CHANGES.txt   2005-12-16 12:28:10 UTC 
(rev 40805)
@@ -26,6 +26,9 @@
 
 Bugs Fixed
 
+  - Collector #1976: FTP STOR command would load the file being
+uploaded in memory. Changed to use a TemporaryFile.
+
   - Collector #1904: On Mac OS X avoid a spurious OSError when
 zopectl exits.
 

Modified: Zope/branches/Zope-2_8-branch/lib/python/ZServer/FTPRequest.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/ZServer/FTPRequest.py  
2005-12-16 11:58:29 UTC (rev 40804)
+++ Zope/branches/Zope-2_8-branch/lib/python/ZServer/FTPRequest.py  
2005-12-16 12:28:10 UTC (rev 40805)
@@ -27,7 +27,7 @@
 class FTPRequest(HTTPRequest):
 
 def __init__(self, path, command, channel, response, stdin=None,
- environ=None,globbing=None,recursive=0):
+ environ=None, globbing=None, recursive=0, size=None):
 
 # we need to store the globbing information to pass it
 # to the ZPublisher and the manage_FTPlist function
@@ -35,9 +35,12 @@
 self.globbing = globbing
 self.recursive= recursive
 
-if stdin is None: stdin=StringIO()
+if stdin is None:
+size = 0
+stdin = StringIO()
+
 if environ is None:
-environ=self._get_env(path, command, channel, stdin)
+environ = self._get_env(path, command, channel, stdin, size)
 
 self._orig_env=environ
 HTTPRequest.__init__(self, stdin, environ, response, clean=1)
@@ -61,7 +64,7 @@
  )
 return r
 
-def _get_env(self, path, command, channel, stdin):
+def _get_env(self, path, command, channel, stdin, size):
 Returns a CGI style environment
 env={}
 env['SCRIPT_NAME']='/%s' % channel.module
@@ -109,9 +112,10 @@
 env['QUERY_STRING']='id=%snew_id=%s' % (args[0],args[1])
 
 elif command=='STOR':
-env['PATH_INFO']=self._join_paths(channel.path, path)
-env['REQUEST_METHOD']='PUT'
-env['CONTENT_LENGTH']=len(stdin.getvalue())
+env['PATH_INFO'] = self._join_paths(channel.path, path)
+env['REQUEST_METHOD'] = 'PUT'
+env['CONTENT_LENGTH'] = long(size)
+
 else:
 env['PATH_INFO']=self._join_paths(channel.path, path, command)
 

Modified: Zope/branches/Zope-2_8-branch/lib/python/ZServer/FTPServer.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/ZServer/FTPServer.py   
2005-12-16 11:58:29 UTC (rev 40804)
+++ Zope/branches/Zope-2_8-branch/lib/python/ZServer/FTPServer.py   
2005-12-16 12:28:10 UTC (rev 40805)
@@ -352,7 +352,7 @@
 # Right now we are limited in the errors we can issue, since
 # we agree to accept the file before checking authorization
 
-fd=ContentReceiver(self.stor_callback, line[1])
+fd = ContentReceiver(self.stor_callback, line[1])
 self.respond (
 '150 Opening %s connection for %s' % (
 self.type_map[self.current_mode],
@@ -361,14 +361,15 @@
 )
 self.make_recv_channel(fd)
 
-def stor_callback(self,path,data):
+def stor_callback(self, path, data, size):
 'callback to do the STOR, after we have the input'
-response=make_response(self, self.stor_completion)
-request=FTPRequest(path,'STOR',self,response,stdin=data)
-handle(self.module,request,response)
+response = make_response(self, self.stor_completion)
+request = FTPRequest(path, 'STOR', self, response,
+ stdin=data, size=size)
+handle(self.module, request, response)
 
-def stor_completion(self,response):
-status=response.getStatus()
+def stor_completion(self, response):
+status = response.getStatus()
 
 if status in (200, 201, 204, 302):
 self.client_dc.channel.respond('226 Transfer complete.')
@@ -559,19 +560,21 @@
 Write-only file object used to receive data from FTP
 
 def __init__(self,callback,*args):
-self.data=StringIO()
-self.callback=callback
-self.args=args
+from tempfile import TemporaryFile
+self.data = TemporaryFile('w+b')
+self.callback 

[Zope-Checkins] SVN: Zope/branches/2.9/ - Collector #1976: FTP STOR command would load the file being

2005-12-16 Thread Sidnei da Silva
Log message for revision 40806:
  
   - Collector #1976: FTP STOR command would load the file being
 uploaded in memory. Changed to use a TemporaryFile.
  

Changed:
  U   Zope/branches/2.9/doc/CHANGES.txt
  U   Zope/branches/2.9/lib/python/ZServer/FTPRequest.py
  U   Zope/branches/2.9/lib/python/ZServer/FTPServer.py

-=-
Modified: Zope/branches/2.9/doc/CHANGES.txt
===
--- Zope/branches/2.9/doc/CHANGES.txt   2005-12-16 12:28:10 UTC (rev 40805)
+++ Zope/branches/2.9/doc/CHANGES.txt   2005-12-16 12:49:12 UTC (rev 40806)
@@ -27,6 +27,9 @@
 
 Bugs fixed
 
+ - Collector #1976: FTP STOR command would load the file being
+   uploaded in memory. Changed to use a TemporaryFile.
+
  - OFS ObjectManager: Fixed list_imports() to tolerate missing
import directories.
 

Modified: Zope/branches/2.9/lib/python/ZServer/FTPRequest.py
===
--- Zope/branches/2.9/lib/python/ZServer/FTPRequest.py  2005-12-16 12:28:10 UTC 
(rev 40805)
+++ Zope/branches/2.9/lib/python/ZServer/FTPRequest.py  2005-12-16 12:49:12 UTC 
(rev 40806)
@@ -27,7 +27,7 @@
 class FTPRequest(HTTPRequest):
 
 def __init__(self, path, command, channel, response, stdin=None,
- environ=None,globbing=None,recursive=0):
+ environ=None, globbing=None, recursive=0, size=None):
 
 # we need to store the globbing information to pass it
 # to the ZPublisher and the manage_FTPlist function
@@ -35,9 +35,12 @@
 self.globbing = globbing
 self.recursive= recursive
 
-if stdin is None: stdin=StringIO()
+if stdin is None:
+size = 0
+stdin = StringIO()
+
 if environ is None:
-environ=self._get_env(path, command, channel, stdin)
+environ = self._get_env(path, command, channel, stdin, size)
 
 self._orig_env=environ
 HTTPRequest.__init__(self, stdin, environ, response, clean=1)
@@ -61,7 +64,7 @@
  )
 return r
 
-def _get_env(self, path, command, channel, stdin):
+def _get_env(self, path, command, channel, stdin, size):
 Returns a CGI style environment
 env={}
 env['SCRIPT_NAME']='/%s' % channel.module
@@ -109,9 +112,10 @@
 env['QUERY_STRING']='id=%snew_id=%s' % (args[0],args[1])
 
 elif command=='STOR':
-env['PATH_INFO']=self._join_paths(channel.path, path)
-env['REQUEST_METHOD']='PUT'
-env['CONTENT_LENGTH']=len(stdin.getvalue())
+env['PATH_INFO'] = self._join_paths(channel.path, path)
+env['REQUEST_METHOD'] = 'PUT'
+env['CONTENT_LENGTH'] = long(size)
+
 else:
 env['PATH_INFO']=self._join_paths(channel.path, path, command)
 

Modified: Zope/branches/2.9/lib/python/ZServer/FTPServer.py
===
--- Zope/branches/2.9/lib/python/ZServer/FTPServer.py   2005-12-16 12:28:10 UTC 
(rev 40805)
+++ Zope/branches/2.9/lib/python/ZServer/FTPServer.py   2005-12-16 12:49:12 UTC 
(rev 40806)
@@ -352,7 +352,7 @@
 # Right now we are limited in the errors we can issue, since
 # we agree to accept the file before checking authorization
 
-fd=ContentReceiver(self.stor_callback, line[1])
+fd = ContentReceiver(self.stor_callback, line[1])
 self.respond (
 '150 Opening %s connection for %s' % (
 self.type_map[self.current_mode],
@@ -361,14 +361,15 @@
 )
 self.make_recv_channel(fd)
 
-def stor_callback(self,path,data):
+def stor_callback(self, path, data, size):
 'callback to do the STOR, after we have the input'
-response=make_response(self, self.stor_completion)
-request=FTPRequest(path,'STOR',self,response,stdin=data)
-handle(self.module,request,response)
+response = make_response(self, self.stor_completion)
+request = FTPRequest(path, 'STOR', self, response,
+ stdin=data, size=size)
+handle(self.module, request, response)
 
-def stor_completion(self,response):
-status=response.getStatus()
+def stor_completion(self, response):
+status = response.getStatus()
 
 if status in (200, 201, 204, 302):
 self.client_dc.channel.respond('226 Transfer complete.')
@@ -559,19 +560,21 @@
 Write-only file object used to receive data from FTP
 
 def __init__(self,callback,*args):
-self.data=StringIO()
-self.callback=callback
-self.args=args
+from tempfile import TemporaryFile
+self.data = TemporaryFile('w+b')
+self.callback = callback
+self.args = args
 
 def write(self,data):
 self.data.write(data)
 
 def close(self):
+size = self.data.tell()
 

[Zope-Checkins] SVN: Zope/trunk/ - Collector #1976: FTP STOR command would load the file being

2005-12-16 Thread Sidnei da Silva
Log message for revision 40807:
  
   - Collector #1976: FTP STOR command would load the file being
 uploaded in memory. Changed to use a TemporaryFile.
  

Changed:
  U   Zope/trunk/doc/CHANGES.txt
  U   Zope/trunk/lib/python/ZServer/FTPRequest.py
  U   Zope/trunk/lib/python/ZServer/FTPServer.py

-=-
Modified: Zope/trunk/doc/CHANGES.txt
===
--- Zope/trunk/doc/CHANGES.txt  2005-12-16 12:49:12 UTC (rev 40806)
+++ Zope/trunk/doc/CHANGES.txt  2005-12-16 12:49:26 UTC (rev 40807)
@@ -120,6 +120,9 @@
 
 Bugs Fixed
 
+  - Collector #1976: FTP STOR command would load the file being
+uploaded in memory. Changed to use a TemporaryFile.
+
   - OFS ObjectManager: Fixed list_imports() to tolerate missing
 import directories.
 

Modified: Zope/trunk/lib/python/ZServer/FTPRequest.py
===
--- Zope/trunk/lib/python/ZServer/FTPRequest.py 2005-12-16 12:49:12 UTC (rev 
40806)
+++ Zope/trunk/lib/python/ZServer/FTPRequest.py 2005-12-16 12:49:26 UTC (rev 
40807)
@@ -27,7 +27,7 @@
 class FTPRequest(HTTPRequest):
 
 def __init__(self, path, command, channel, response, stdin=None,
- environ=None,globbing=None,recursive=0):
+ environ=None, globbing=None, recursive=0, size=None):
 
 # we need to store the globbing information to pass it
 # to the ZPublisher and the manage_FTPlist function
@@ -35,9 +35,12 @@
 self.globbing = globbing
 self.recursive= recursive
 
-if stdin is None: stdin=StringIO()
+if stdin is None:
+size = 0
+stdin = StringIO()
+
 if environ is None:
-environ=self._get_env(path, command, channel, stdin)
+environ = self._get_env(path, command, channel, stdin, size)
 
 self._orig_env=environ
 HTTPRequest.__init__(self, stdin, environ, response, clean=1)
@@ -61,7 +64,7 @@
  )
 return r
 
-def _get_env(self, path, command, channel, stdin):
+def _get_env(self, path, command, channel, stdin, size):
 Returns a CGI style environment
 env={}
 env['SCRIPT_NAME']='/%s' % channel.module
@@ -109,9 +112,10 @@
 env['QUERY_STRING']='id=%snew_id=%s' % (args[0],args[1])
 
 elif command=='STOR':
-env['PATH_INFO']=self._join_paths(channel.path, path)
-env['REQUEST_METHOD']='PUT'
-env['CONTENT_LENGTH']=len(stdin.getvalue())
+env['PATH_INFO'] = self._join_paths(channel.path, path)
+env['REQUEST_METHOD'] = 'PUT'
+env['CONTENT_LENGTH'] = long(size)
+
 else:
 env['PATH_INFO']=self._join_paths(channel.path, path, command)
 

Modified: Zope/trunk/lib/python/ZServer/FTPServer.py
===
--- Zope/trunk/lib/python/ZServer/FTPServer.py  2005-12-16 12:49:12 UTC (rev 
40806)
+++ Zope/trunk/lib/python/ZServer/FTPServer.py  2005-12-16 12:49:26 UTC (rev 
40807)
@@ -352,7 +352,7 @@
 # Right now we are limited in the errors we can issue, since
 # we agree to accept the file before checking authorization
 
-fd=ContentReceiver(self.stor_callback, line[1])
+fd = ContentReceiver(self.stor_callback, line[1])
 self.respond (
 '150 Opening %s connection for %s' % (
 self.type_map[self.current_mode],
@@ -361,14 +361,15 @@
 )
 self.make_recv_channel(fd)
 
-def stor_callback(self,path,data):
+def stor_callback(self, path, data, size):
 'callback to do the STOR, after we have the input'
-response=make_response(self, self.stor_completion)
-request=FTPRequest(path,'STOR',self,response,stdin=data)
-handle(self.module,request,response)
+response = make_response(self, self.stor_completion)
+request = FTPRequest(path, 'STOR', self, response,
+ stdin=data, size=size)
+handle(self.module, request, response)
 
-def stor_completion(self,response):
-status=response.getStatus()
+def stor_completion(self, response):
+status = response.getStatus()
 
 if status in (200, 201, 204, 302):
 self.client_dc.channel.respond('226 Transfer complete.')
@@ -559,19 +560,21 @@
 Write-only file object used to receive data from FTP
 
 def __init__(self,callback,*args):
-self.data=StringIO()
-self.callback=callback
-self.args=args
+from tempfile import TemporaryFile
+self.data = TemporaryFile('w+b')
+self.callback = callback
+self.args = args
 
 def write(self,data):
 self.data.write(data)
 
 def close(self):
+size = self.data.tell()
 self.data.seek(0)
-args=self.args+(self.data,)
-c=self.callback
-

[Zope-Checkins] SVN: Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/pt/ptEdit.pt encoding input field is now a hidden field since we enforce UTF-8

2005-12-16 Thread Andreas Jung
Log message for revision 40809:
  encoding input field is now a hidden field since we enforce UTF-8
  

Changed:
  U   
Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/pt/ptEdit.pt

-=-
Modified: 
Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/pt/ptEdit.pt
===
--- 
Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/pt/ptEdit.pt
  2005-12-16 13:37:46 UTC (rev 40808)
+++ 
Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/pt/ptEdit.pt
  2005-12-16 13:45:46 UTC (rev 40809)
@@ -54,7 +54,7 @@
   tr 
 td align=left valign=middle class=form-labelEncoding/td
 td
-  input type=text readonly name=encoding tal:attributes=value 
context/pt_encoding style=background-color: #bb; /
+  input type=hidden name=encoding tal:attributes=value 
context/pt_encoding /
 /td
   /tr
 

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


[Zope-Checkins] SVN: Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ZopePageTemplate.py removed debug output

2005-12-16 Thread Andreas Jung
Log message for revision 40812:
  removed debug output
  

Changed:
  U   
Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ZopePageTemplate.py

-=-
Modified: 
Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ZopePageTemplate.py
===
--- 
Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ZopePageTemplate.py
   2005-12-16 15:14:52 UTC (rev 40811)
+++ 
Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ZopePageTemplate.py
   2005-12-16 15:16:50 UTC (rev 40812)
@@ -130,7 +130,6 @@
 security.declareProtected(change_page_templates, 'pt_encoding')
 def pt_encoding(self):
 encoding = sniffEncoding(self.read())
-print encoding
 return encoding
 
 from ComputedAttribute import ComputedAttribute
@@ -142,6 +141,7 @@
 text = text.strip()
 if not isinstance(text, unicode):
 text = unicode(text, encoding)
+
 self.ZCacheable_invalidate()
 PageTemplate.pt_edit(self, text, content_type)
 

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


[Zope-Checkins] SVN: Zope/trunk/lib/python/ New zdaemon.

2005-12-16 Thread Tim Peters
Log message for revision 40813:
  New zdaemon.
  
  This fixes an intermittent test-killing race in
  testRunIgnoresParentSignals, which was introduced
  the last time a new zdaemon got stitched in.
  

Changed:
  _U  Zope/trunk/lib/python/

-=-

Property changes on: Zope/trunk/lib/python
___
Name: svn:externals
   - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZopeUndo
zdaemon-r 39732 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz
zodbcode   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode
ClientCookie   -r 40549 
svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie
mechanize  -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize

   + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/BTrees
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b4/src/ZopeUndo
zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon
pytz   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/pytz
zodbcode   -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/zodbcode
ClientCookie   -r 40549 
svn://svn.zope.org/repos/main/Zope3/trunk/src/ClientCookie
mechanize  -r 40549 svn://svn.zope.org/repos/main/Zope3/trunk/src/mechanize


___
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/Testing/ZopeTestCase/ Made sure logging is configured. Read $INSTANCE_HOME/log.ini if it exists.

2005-12-16 Thread Stefan H. Holek
Log message for revision 40819:
  Made sure logging is configured. Read $INSTANCE_HOME/log.ini if it exists.
  

Changed:
  U   Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/ZopeLite.py
  U   
Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/doc/CHANGES.txt
  U   
Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/ztc_common.py

-=-
Modified: 
Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/ZopeLite.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/ZopeLite.py   
2005-12-16 18:22:04 UTC (rev 40818)
+++ Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/ZopeLite.py   
2005-12-16 18:40:14 UTC (rev 40819)
@@ -58,8 +58,9 @@
 
 def _configure_logging():
 # Initialize the logging module
-if not sys.modules.has_key('logging'):
-import logging
+import logging
+root = logging.getLogger()
+if not root.handlers:
 logging.basicConfig()
 
 def _configure_debug_mode():

Modified: 
Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/doc/CHANGES.txt
===
--- 
Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/doc/CHANGES.txt   
2005-12-16 18:22:04 UTC (rev 40818)
+++ 
Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/doc/CHANGES.txt   
2005-12-16 18:40:14 UTC (rev 40819)
@@ -5,6 +5,7 @@
 - installProduct() now becomes a noop if ZopeTestCase did not apply its
   patches.
 - Made the functional doc tests set the cookie related headers.
+- Made sure logging is configured. Read $INSTANCE_HOME/log.ini if it exists.
 
 0.9.8 (Zope 2.8 edition)
 - Renamed 'doctest' package to 'zopedoctest' because of name-shadowing

Modified: 
Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/ztc_common.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/ztc_common.py 
2005-12-16 18:22:04 UTC (rev 40818)
+++ Zope/branches/Zope-2_8-branch/lib/python/Testing/ZopeTestCase/ztc_common.py 
2005-12-16 18:40:14 UTC (rev 40819)
@@ -17,7 +17,7 @@
   execfile(os.path.join(os.path.dirname(Testing.__file__),
'ZopeTestCase', 'ztc_common.py'))
 
-$Id: ztc_common.py,v 1.14 2004/05/27 15:06:24 shh42 Exp $
+$Id$
 
 
 # Overwrites the default framework() method to expose the
@@ -62,11 +62,13 @@
 return
 if self.zeo_instance_home:
 self.setup_zeo_instance_home()
+self.setup_logging()
 else:
 if self.instance_home:
 self.setup_instance_home()
 else:
 self.detect_and_setup_instance_home()
+self.setup_logging()
 self.setup_custom_zodb()
 
 def setup_zeo_instance_home(self):
@@ -128,6 +130,13 @@
 os.environ['INSTANCE_HOME'] = INSTANCE_HOME = self.cwd
 self.setconfig(instancehome=self.cwd)
 
+def setup_logging(self):
+'''If $INSTANCE_HOME/log.ini exists, load it.'''
+logini = os.path.join(self.getconfig('instancehome'), 'log.ini')
+if os.path.exists(logini):
+import logging.config
+logging.config.fileConfig(logini)
+
 def add_instance(self, p):
 '''Adds an INSTANCE_HOME directory to Products.__path__ and 
sys.path.'''
 import Products

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


[Zope-Checkins] SVN: Zope/trunk/lib/python/Testing/ZopeTestCase/ Merged Zope-2_8-branch -r40818:40819 into the trunk.

2005-12-16 Thread Stefan H. Holek
Log message for revision 40821:
  Merged Zope-2_8-branch -r40818:40819 into the trunk.
  (Made sure logging is configured. Read $INSTANCE_HOME/log.ini if it exists.)
  

Changed:
  U   Zope/trunk/lib/python/Testing/ZopeTestCase/ZopeLite.py
  U   Zope/trunk/lib/python/Testing/ZopeTestCase/doc/CHANGES.txt
  U   Zope/trunk/lib/python/Testing/ZopeTestCase/ztc_common.py

-=-
Modified: Zope/trunk/lib/python/Testing/ZopeTestCase/ZopeLite.py
===
--- Zope/trunk/lib/python/Testing/ZopeTestCase/ZopeLite.py  2005-12-16 
18:44:55 UTC (rev 40820)
+++ Zope/trunk/lib/python/Testing/ZopeTestCase/ZopeLite.py  2005-12-16 
18:46:32 UTC (rev 40821)
@@ -58,8 +58,9 @@
 
 def _configure_logging():
 # Initialize the logging module
-if not sys.modules.has_key('logging'):
-import logging
+import logging
+root = logging.getLogger()
+if not root.handlers:
 logging.basicConfig()
 
 def _configure_debug_mode():

Modified: Zope/trunk/lib/python/Testing/ZopeTestCase/doc/CHANGES.txt
===
--- Zope/trunk/lib/python/Testing/ZopeTestCase/doc/CHANGES.txt  2005-12-16 
18:44:55 UTC (rev 40820)
+++ Zope/trunk/lib/python/Testing/ZopeTestCase/doc/CHANGES.txt  2005-12-16 
18:46:32 UTC (rev 40821)
@@ -6,6 +6,7 @@
 - installProduct() now becomes a noop if ZopeTestCase did not apply its
   patches.
 - Made the functional doc tests set the cookie related headers.
+- Made sure logging is configured. Read $INSTANCE_HOME/log.ini if it exists.
 
 0.9.8 (Zope 2.8 edition)
 - Renamed 'doctest' package to 'zopedoctest' because of name-shadowing

Modified: Zope/trunk/lib/python/Testing/ZopeTestCase/ztc_common.py
===
--- Zope/trunk/lib/python/Testing/ZopeTestCase/ztc_common.py2005-12-16 
18:44:55 UTC (rev 40820)
+++ Zope/trunk/lib/python/Testing/ZopeTestCase/ztc_common.py2005-12-16 
18:46:32 UTC (rev 40821)
@@ -17,7 +17,7 @@
   execfile(os.path.join(os.path.dirname(Testing.__file__),
'ZopeTestCase', 'ztc_common.py'))
 
-$Id: ztc_common.py,v 1.14 2004/05/27 15:06:24 shh42 Exp $
+$Id$
 
 
 # Overwrites the default framework() method to expose the
@@ -62,11 +62,13 @@
 return
 if self.zeo_instance_home:
 self.setup_zeo_instance_home()
+self.setup_logging()
 else:
 if self.instance_home:
 self.setup_instance_home()
 else:
 self.detect_and_setup_instance_home()
+self.setup_logging()
 self.setup_custom_zodb()
 
 def setup_zeo_instance_home(self):
@@ -128,6 +130,13 @@
 os.environ['INSTANCE_HOME'] = INSTANCE_HOME = self.cwd
 self.setconfig(instancehome=self.cwd)
 
+def setup_logging(self):
+'''If $INSTANCE_HOME/log.ini exists, load it.'''
+logini = os.path.join(self.getconfig('instancehome'), 'log.ini')
+if os.path.exists(logini):
+import logging.config
+logging.config.fileConfig(logini)
+
 def add_instance(self, p):
 '''Adds an INSTANCE_HOME directory to Products.__path__ and 
sys.path.'''
 import Products

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


[Zope-dev] Zope tests:

2005-12-16 Thread Zope tests summarizer
Summary of messages to the zope-tests list.
Period Thu Dec 15 12:01:02 2005 UTC to Fri Dec 16 12:01:02 2005 UTC.
There were no messages.

___
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 branches 2.9 2.4 Linux zc-buildbot

2005-12-16 Thread buildbot
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux 
zc-buildbot.

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

Build Reason: changes
Build Source Stamp: 2253
Blamelist: andreasjung,jim,jinty,jmo,sidnei

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 )


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

2005-12-16 Thread 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: 2254
Blamelist: andreasjung,ctheune,jim,jinty,jmo,sidnei,tim_one,tseaver,yuppie

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 )


[Zope-dev] buildbot failure in Zope trunk 2.4 Windows 2000 zc-bbwin

2005-12-16 Thread buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000 
zc-bbwin.

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

Build Reason: changes
Build Source Stamp: 2254
Blamelist: andreasjung,ctheune,jim,jinty,jmo,sidnei,tim_one,tseaver,yuppie

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 )


[Zope-dev] buildbot failure in Zope branches 2.9 2.4 Windows 2000 zc-bbwin

2005-12-16 Thread buildbot
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Windows 2000 
zc-bbwin.

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

Build Reason: changes
Build Source Stamp: 2253
Blamelist: andreasjung,jim,jinty,jmo,sidnei

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 )


[Zope-dev] buildbot failure in Zope trunk 2.4 Windows 2000 zc-bbwin

2005-12-16 Thread buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000 
zc-bbwin.

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

Build Reason: changes
Build Source Stamp: 2260
Blamelist: andreasjung,hdima,mgedmin,tim_one

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 )


[Zope-dev] Test Failures

2005-12-16 Thread Sidnei da Silva
I've seen the following tests fail today, after updating Zope 2.8
branch for all variants of BTrees:

==
ERROR: testUpdateFromPersistentMapping
(BTrees.tests.testBTrees.IIBucketTest)
--
Traceback (most recent call last):
  File /usr/lib/python2.4/unittest.py, line 260, in run
testMethod()
  File
  /home/sidnei/src/zope/2.8/lib/python/BTrees/tests/testBTrees.py,
  line 353, in testUpdateFromPersistentMapping
self.t.update(pm)
TypeError: Sequence must contain 2-item tuples

This is on a Powerbook running Ubuntu Breezy PPC.

Python 2.4.2 (#2, Nov 20 2005, 17:20:59)
[GCC 4.0.3 20051023 (prerelease) (Ubuntu 4.0.2-3ubuntu1)] on linux2
Type help, copyright, credits or license for more information.

Additionally, while running the tests for Zope 2.8, 2.9 and trunk (all
at the same time *wink*), the following tests failed. I suspect the
failures have to do with heavy load on the box while running the
tests?

Zope 2.8:

==
FAIL: testPathologicalLeftBranching
(Products.Transience.tests.testTransientObjectContainer.TestTransientObjectContainer)
--
==
FAIL: testPathologicalRightBranching
(Products.Transience.tests.testTransientObjectContainer.TestTransientObjectContainer)
--


Zope 2.9:

Error in test testPathologicalLeftBranching
(Products.Transience.tests.testTransientObjectContainer.TestTransientObjectContainer)

Failure in test testPathologicalRightBranching
(Products.Transience.tests.testTransientObjectContainer.TestTransientObjectContainer)

Failure in test testRandomNonOverlappingInserts
(Products.Transience.tests.testTransientObjectContainer.TestTransientObjectContainer)


Zope trunk:

Failure in test testPathologicalLeftBranching
(Products.Transience.tests.testTransientObjectContainer.TestTransientObjectContainer)

-- 
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] RE: [ZODB-Dev] Test Failures

2005-12-16 Thread Tim Peters
[Sidnei da Silva]
 I've seen the following tests fail today, after updating Zope 2.8 branch
 for all variants of BTrees:

 ==
 ERROR: testUpdateFromPersistentMapping
 (BTrees.tests.testBTrees.IIBucketTest)
 --
 Traceback (most recent call last):
   File /usr/lib/python2.4/unittest.py, line 260, in run
 testMethod()
   File
   /home/sidnei/src/zope/2.8/lib/python/BTrees/tests/testBTrees.py,
   line 353, in testUpdateFromPersistentMapping
 self.t.update(pm)
 TypeError: Sequence must contain 2-item tuples

 This is on a Powerbook running Ubuntu Breezy PPC.

 Python 2.4.2 (#2, Nov 20 2005, 17:20:59)
 [GCC 4.0.3 20051023 (prerelease)
 (Ubuntu 4.0.2-3ubuntu1)] on linux2
 Type help, copyright, credits or license for more information.

Works for me:

[EMAIL PROTECTED]:~/Zope2.8$ svn info
Path: .
URL: svn://svn.zope.org/repos/main/Zope/branches/Zope-2_8-branch
Repository UUID: 62d5b8a3-27da-0310-9561-8e5933582275
Revision: 40815
Node Kind: directory
Schedule: normal
Last Changed Author: sidnei
Last Changed Rev: 40805
Last Changed Date: 2005-12-16 07:28:10 -0500 (Fri, 16 Dec 2005)
Properties Last Updated: 2005-10-04 14:30:34 -0400 (Tue, 04 Oct 2005)

[EMAIL PROTECTED]:~/Zope2.8$ svn up
Fetching external item into 'doc/ZEO'
External at revision 40815.
Fetching external item into 'lib/python/zope'
External at revision 40815.
Fetching external item into 'lib/python/ZConfig'
External at revision 40815.
Fetching external item into 'lib/python/BTrees'
External at revision 40815.
Fetching external item into 'lib/python/Persistence'
External at revision 40815.
Fetching external item into 'lib/python/persistent'
External at revision 40815.
Fetching external item into 'lib/python/ThreadedAsync'
External at revision 40815.
Fetching external item into 'lib/python/transaction'
External at revision 40815.
Fetching external item into 'lib/python/ZEO'
External at revision 40815.
Fetching external item into 'lib/python/ZODB'
External at revision 40815.
Fetching external item into 'lib/python/ZopeUndo'
External at revision 40815.
Fetching external item into 'lib/python/zdaemon'
External at revision 40815.
Fetching external item into 'utilities/ZODBTools'
External at revision 40815.
At revision 40815.

[EMAIL PROTECTED]:~/Zope2.8$ python2.4
Python 2.4.2 (#1, Dec  2 2005, 10:17:25)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] on linux2
...

[EMAIL PROTECTED]:~/Zope2.8$ python2.4 setup.py build_ext -i
running build_ext
running build_ext

[EMAIL PROTECTED]:~/Zope2.8$ python2.4 test.py -vv . 
testUpdateFromPersistentMapping
Running unit tests at level 1
Running unit tests from /home/tim/Zope2.8/lib/python
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IIBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IIBTreeTest) ... ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IFBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IFBTreeTest) ... ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IOBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.IOBTreeTest) ... ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.OOBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.OOBTreeTest) ... ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.OIBucketTest) ...
ok
testUpdateFromPersistentMapping (BTrees.tests.testBTrees.OIBTreeTest) ... ok

--
Ran 10 tests in 0.007s

OK

No idea why it failed for you.  The only thing that rings a bell here is
that this test was added in ZODB 3.4.2b1, corresponding to this ZODB news
entry:


BTrees
--

- (3.4.2b1) Collector 1873.  It wasn't possible to construct a BTree
  or Bucket from, or apply their update() methods to, a PersistentMapping
  or PersistentDict.  This works now.


So my only guesses are that you have some older (than 3.4.2) version of ZODB
on your PYTHONPATH, or that your checkout is screwed up.  Here are the
externals you _should_ have:

[EMAIL PROTECTED]:~/Zope2.8$ svn propget svn:externals lib/python
zope
svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope
ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/BTrees
Persistencesvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/Persistence
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/persistent
ThreadedAsync
svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZopeUndo
zdaemon  

[Zope-dev] RE: [ZODB-Dev] Test Failures

2005-12-16 Thread Tim Peters
 [Sidnei]
 I've seen the following tests fail today, after updating Zope 2.8 branch
 ...
 Python 2.4.2 (#2, Nov 20 2005, 17:20:59)
 ...

BTW, I think the Official Story is that Python 2.4+ is still not supported
for Zope 2.8.  I ran all the stuff in my reply with 2.4.2 too.  Doesn't
matter, though -- I got the same results (no problems) with Python 2.3.5.

___
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: [ZODB-Dev] Test Failures

2005-12-16 Thread Sidnei da Silva
| No idea why it failed for you.  The only thing that rings a bell here is
| that this test was added in ZODB 3.4.2b1, corresponding to this ZODB news
| entry:
| 
| 
| BTrees
| --
| 
| - (3.4.2b1) Collector 1873.  It wasn't possible to construct a BTree
|   or Bucket from, or apply their update() methods to, a PersistentMapping
|   or PersistentDict.  This works now.
| 
| 
| So my only guesses are that you have some older (than 3.4.2) version of ZODB
| on your PYTHONPATH, or that your checkout is screwed up.  Here are the
| externals you _should_ have:

But, why only the 2.8 tests would fail then? I'll try a 'make clean'
before running the tests and see if it helps.

| [EMAIL PROTECTED]:~/Zope2.8$ svn propget svn:externals lib/python
| zope
| svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope
| ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3
| BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/BTrees
| Persistencesvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/Persistence
| persistent svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/persistent
| ThreadedAsync
| svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ThreadedAsync
| transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/transaction
| ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZEO
| ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZODB
| ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZopeUndo
| zdaemonsvn://svn.zope.org/repos/main/zdaemon/tags/zdaemon-1.1

Looks good to me:

[EMAIL PROTECTED]:~/src/zope/2.8$ svn propget svn:externals lib/python
zope   
svn://svn.zope.org/repos/main/Zope3/tags/ZopeX3-3.0.1-Zope-2.8/src/zope
ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3
BTrees svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/BTrees
Persistencesvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/Persistence
persistent svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/persistent
ThreadedAsync  svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ThreadedAsync
transactionsvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/transaction
ZEOsvn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZEO
ZODB   svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZODB
ZopeUndo   svn://svn.zope.org/repos/main/ZODB/tags/3.4.2/src/ZopeUndo
zdaemonsvn://svn.zope.org/repos/main/zdaemon/tags/zdaemon-1.1

| 
|  Additionally, while running the tests for Zope 2.8, 2.9 and trunk (all
|  at the same time *wink*), the following tests failed. I suspect the
|  failures have to do with heavy load on the box while running the tests?
| 
| Almost certainly, yes.  The Transience tests are part of Zope (not part of
| ZODB), and it's in the nature of transient objects that they go away by
| magic as time passes.  If too much wall-clock time elapses while a
| Transience test is running, failure is expected.

Running all the tests takes 1864 seconds, so I can see it taking too
long :)

-- 
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-dev] Re: [ZODB-Dev] Test Failures

2005-12-16 Thread Sidnei da Silva
On Fri, Dec 16, 2005 at 03:01:59PM -0200, Sidnei da Silva wrote:
| But, why only the 2.8 tests would fail then? I'll try a 'make clean'
| before running the tests and see if it helps.

That did indeed help, sorry for the noise.

-- 
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] RE: [ZODB-Dev] Test Failures

2005-12-16 Thread Tim Peters
[Sidnei da Silva]
 But, why only the 2.8 tests would fail then?

Hey, it's your machine, you figure it out ;-)  Note that test.py in 2.8 has
little in common with the test.py in 2.9 or Zope trunk, and they may very
well react in different ways to quirks in your environment.

 I'll try a 'make clean' before running the tests and see if it helps.

Probably not, but who knows.  If that doesn't help, add code to dump
sys.path and stare at it.  And/or add code to import ZODB and print
ZODB.__version__, to see which version you're really getting during the
tests.

Ah, since the fix for Collector 1873 required changing C code, I do expect
those tests would fail if you didn't recompile Zope 2.8 since the time the C
code changed.

___
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

2005-12-16 Thread 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: 2268
Blamelist: hdima,mgedmin,shh,yuppie

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 )


Retiring ZODB 3.2 (was: Re: [Zope-dev] FTP Upload killing Zope)

2005-12-16 Thread Tim Peters
[Andreas Jung, on zope-dev; Tim added zodb-dev to this msg]
 I would like to consider the 2.7 branch closed for any kind of fixes except
 security related fixes. I don't plan any further 2.7 releases.

In that case (which is fine by me), I'll stop porting fixes to the
ZODB 3.2 line too.  No changes have been made to that since ZODB
3.2.10 was released on 12-Oct-2005, corresponding to the ZODB shipped
with Zope 2.7.8.
___
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] user account defined outside context of object being accessed

2005-12-16 Thread Kees de Brabander

- Original Message - 
From: Dieter Maurer [EMAIL PROTECTED]
To: Kees de Brabander [EMAIL PROTECTED]
Cc: zope@zope.org
Sent: Thursday, December 15, 2005 5:54 PM
Subject: Re: [Zope] user account defined outside context of object being
accessed


 Kees de Brabander wrote at 2005-12-13 22:40 +0100:
  ...
   Module AccessControl.ImplPython, line 449, in validate
   Module AccessControl.ImplPython, line 774, in raiseVerbose
 Unauthorized: Your user account is defined outside the context of the
object
 being accessed.  Access to 'f1_index' of (Folder at /f1), acquired
through
 (Folder at /f1/f11/f111), denied. Your user account, user1, exists at
 /f1/f11/acl_users. Access requires one of the following roles:
 ['Authenticated', 'Manager', 'Owner', 'student'].

 A user defined in /f1/f11/acl_users tries to access the protected
 /f1/f1_index. This is not allowed by Zope security system:
 a user defined in a user folder can only access protected objects
 governed by this user folder.

 In your case, all objects at or below /f1/f11 is governed by
 your user folder (/f1/f11/acl_users). /f1/f1_index does not lie
 within this hierarchy and is therefore not governed.

I am painfully aware now that this is the case, at least starting from zope
2.7.8. I have not tested all versions of zope, but at least up to 2.7.3 zope
had no problem with such a set up.

___
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] à l'aide

2005-12-16 Thread Vlada Macek
[At 15.12.2005 20:31, Tino Wildenhain kindly sent the following quotation.]

 You need python2.3.5 or higher and also -dev libs of it. If you run
 stable your python might be too far back

Some day maybe, but AFAIK not yet: Debian Sarge (stable release) has
Python 2.3.5 (default, dependency package python) and 2.4.1 (package
python2.4) officially. Debian testing and unstable releases has python
2.4.2.

I'm happily using compiled Zope against debian python package on my
Sarge server.

-- 

\//\/\
(Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.)

___
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] à l'aide

2005-12-16 Thread bruno desthuilliers
adeline nombre wrote:
 bonjour
 je suis un débutant. je veux installer zope sur la debian. mais j'ai
 remarqué un repertoire /usr/lib/zope. j'ai donc conclu que zope a été
 installé avec mon system debian. maintenant comment faire pour démarer
 zope. dois-je faire un start et où?
 merci

Hi.

First, please dont post in french here, this is an english-speaking list.

Havin zope libs installed is mandatory, but not enough - you now need to
create a zope instance (the actual server).

/usr/lib/zope holds zope's libs, as well as some utilities in the bin
subdirectory. One of these utilies is named mkzopeintance.py, and you
have to use it to create your Zope instance. mkzopeinstance will ask you
where you want to install the instance, and for an admin name and
password. Once done, you can start that instance with
path/to/your/zope/instance/bin/zopectl/start, then point your browser
to localhost:8080/manage, log in, and enjoy !-)

HTH
-- 
bruno desthuilliers
développeur
[EMAIL PROTECTED]
http://www.modulix.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] à l'aide

2005-12-16 Thread Rakotomandimby Mihamina
On Thu, 2005-12-15 at 20:31 +0100, Tino Wildenhain wrote:
 Even on debian its recommended to install zope from source.

Debian/Ubuntu zope packages have interesting zope instances handlers.
It would be nice you try them out and see it is worth to use in some
case.

-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source  GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads  documentation.
Free hosting of CPS groupware: http://www.objectis.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] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
Thanks; this is a problem we are well aware of. Our solution is to
increase the amount of workers, obviously.

However, I'm increasingly getting a feeling that for a rather big
range of unlikely situations that are nonetheless to be expected, Zope
doesn't work _at all_. In a WebServices setting, situations like the
one I described, with one server calling back to another server within
a call from that latter server and both not knowing anything about the
implementation of the other, it would most certainly be extremely hard
to foresee the exact setup of such situations and impossible to
exclude them for persistent objects that actually _do_ change state
(unlike mine). The solution is to not have state in your objects, and
thus lose instantly most of what Zope is.

However, as I see it, the problem is that what Zope actually _is_
(i.e. mostly the ZODB) is an unhealthy way of coupling data and
implementation (which is _exactly_ why my implementation didn't work
immediately). This of course comes from its origins in TTW development
where there wouldn't actually have been many user made products.

Please tell me if I'm wrong with my assumption above, and why. I'm not
trying to be inflamatory, this just has me really worried.

Ole


2005/12/15, Dieter Maurer [EMAIL PROTECTED]:
 Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100:
 Is it at all impossible to use XML-RPC _within_ a ZOPE architecture?

 In principle yes.

 Be careful however: it is easy to introduce deadlocks!

   When during request processing you call back into the same
   Zope via XML-RPC, the calling out request will not complete
   until the XML-RPC returns a result (this always holds for
   calls, XML-RPC or other, to an external or internal server).

   Zope has a limited amount of workers (the default is 4) able
   to execute requests. If there are no free workers, requests
   have to wait for one.

   Now imagine that as many requests arrive as there are workers
   and each of them wants to perform an XML-RPC against the
   same Zope. Then you have a deadlock: none of the XML-RPC requests
   will finish, because there are no free workers. An no worker
   will ever become free again, because each of them waits for
   its XML-RPC to finish.

 Therefore, you should directly call internal resources (rather
 than use XML-RPC).


 --
 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: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Michael Haubenwallner

Jan-Ole Esleben wrote:


Thanks; this is a problem we are well aware of. Our solution is to
increase the amount of workers, obviously.

However, I'm increasingly getting a feeling that for a rather big
range of unlikely situations that are nonetheless to be expected, Zope
doesn't work _at all_. In a WebServices setting, situations like the
one I described, with one server calling back to another server within
a call from that latter server and both not knowing anything about the
implementation of the other, it would most certainly be extremely hard
to foresee the exact setup of such situations and impossible to
exclude them for persistent objects that actually _do_ change state
(unlike mine). The solution is to not have state in your objects, and
thus lose instantly most of what Zope is.

However, as I see it, the problem is that what Zope actually _is_
(i.e. mostly the ZODB) is an unhealthy way of coupling data and
implementation (which is _exactly_ why my implementation didn't work
immediately). This of course comes from its origins in TTW development
where there wouldn't actually have been many user made products.

Please tell me if I'm wrong with my assumption above, and why. I'm not
trying to be inflamatory, this just has me really worried.

Ole



You could try XMLRPCMethod.
It creates its own worker thread and has a configurable timeout.

Michael

[1] http://www.zope.org/Members/EIONET/XMLRPC

--
http://zope.org/Members/d2m
http://planetzope.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: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
Thanks, I will definitely look into that for my immediate problems.

Ole

2005/12/16, Michael Haubenwallner [EMAIL PROTECTED]:
 Jan-Ole Esleben wrote:

  Thanks; this is a problem we are well aware of. Our solution is to
  increase the amount of workers, obviously.
 
  However, I'm increasingly getting a feeling that for a rather big
  range of unlikely situations that are nonetheless to be expected, Zope
  doesn't work _at all_. In a WebServices setting, situations like the
  one I described, with one server calling back to another server within
  a call from that latter server and both not knowing anything about the
  implementation of the other, it would most certainly be extremely hard
  to foresee the exact setup of such situations and impossible to
  exclude them for persistent objects that actually _do_ change state
  (unlike mine). The solution is to not have state in your objects, and
  thus lose instantly most of what Zope is.
 
  However, as I see it, the problem is that what Zope actually _is_
  (i.e. mostly the ZODB) is an unhealthy way of coupling data and
  implementation (which is _exactly_ why my implementation didn't work
  immediately). This of course comes from its origins in TTW development
  where there wouldn't actually have been many user made products.
 
  Please tell me if I'm wrong with my assumption above, and why. I'm not
  trying to be inflamatory, this just has me really worried.
 
  Ole
 

 You could try XMLRPCMethod.
 It creates its own worker thread and has a configurable timeout.

 Michael

 [1] http://www.zope.org/Members/EIONET/XMLRPC

 --
 http://zope.org/Members/d2m
 http://planetzope.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 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] using tal macros in PloneArticle query

2005-12-16 Thread Stefan Kueppers

Hi all,

I am trying to use tal and metal inside of a PloneArticle instance and 
can not get it to work.

Should this not be possible?

I am aware that kupu needs to be switched to not strip customg tags on 
edit and that there are settings which enable or disble content types in 
the article instance.


I did enable the text/python-source type in the PloneArticle settings, 
but this still seems to not work.


Anyone knows what I might be doing wrong?

Many Thanks!!
Stefan


Bartlett Web Systems
www.bartlett.ucl.ac.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] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Chris McDonough
I don't understand the problem.  How is using XML-RPC incompatible  
with persistence?  What are you trying to exclude?


- C


On Dec 16, 2005, at 6:40 AM, Jan-Ole Esleben wrote:


Thanks; this is a problem we are well aware of. Our solution is to
increase the amount of workers, obviously.

However, I'm increasingly getting a feeling that for a rather big
range of unlikely situations that are nonetheless to be expected, Zope
doesn't work _at all_. In a WebServices setting, situations like the
one I described, with one server calling back to another server within
a call from that latter server and both not knowing anything about the
implementation of the other, it would most certainly be extremely hard
to foresee the exact setup of such situations and impossible to
exclude them for persistent objects that actually _do_ change state
(unlike mine). The solution is to not have state in your objects, and
thus lose instantly most of what Zope is.

However, as I see it, the problem is that what Zope actually _is_
(i.e. mostly the ZODB) is an unhealthy way of coupling data and
implementation (which is _exactly_ why my implementation didn't work
immediately). This of course comes from its origins in TTW development
where there wouldn't actually have been many user made products.

Please tell me if I'm wrong with my assumption above, and why. I'm not
trying to be inflamatory, this just has me really worried.

Ole


2005/12/15, Dieter Maurer [EMAIL PROTECTED]:

Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100:

Is it at all impossible to use XML-RPC _within_ a ZOPE architecture?


In principle yes.

Be careful however: it is easy to introduce deadlocks!

  When during request processing you call back into the same
  Zope via XML-RPC, the calling out request will not complete
  until the XML-RPC returns a result (this always holds for
  calls, XML-RPC or other, to an external or internal server).

  Zope has a limited amount of workers (the default is 4) able
  to execute requests. If there are no free workers, requests
  have to wait for one.

  Now imagine that as many requests arrive as there are workers
  and each of them wants to perform an XML-RPC against the
  same Zope. Then you have a deadlock: none of the XML-RPC requests
  will finish, because there are no free workers. An no worker
  will ever become free again, because each of them waits for
  its XML-RPC to finish.

Therefore, you should directly call internal resources (rather
than use XML-RPC).


--
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 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] using tal macros in PloneArticle query

2005-12-16 Thread J Cameron Cooper

Stefan Kueppers wrote:

I am trying to use tal and metal inside of a PloneArticle instance and 
can not get it to work.

Should this not be possible?


Content is generally static, as part of the whole 
content/logic/presentation concept. I don't know about PloneArticle, but 
I doubt it's any different: the contents are not parsed by anything but 
delivered exactly as is.


If you want behavior, you need a page template. Though there is at least 
one product that provides a type that breaks the rules. DynamicContent 
or something like that.


--jcc
--
Building Websites with Plone
http://plonebook.packtpub.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] batching help

2005-12-16 Thread Martijn Pieters
On 12/15/05, Nicolas Georgakopoulos [EMAIL PROTECTED] wrote:
 Hello all , I'm trying to display on the same page a table with (3
 columns) with content from a list . I'm trying to batch the results so
 that every 3 elements anothe row is created.
 Can anyone give me a clue how to do that ?

Use batches and the following recipe:

http://zopelabs.com/cookbook/998066576


--
Martijn Pieters
___
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] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
 I don't understand the problem.  How is using XML-RPC incompatible
 with persistence?  What are you trying to exclude?

I'm sorry, but I don't understand _that_ question. What am I trying to
_exclude_?

XML-RPC and (the concept of) persistence aren't incompatible. XML-RPC
(on a ZOPE server) and ZOPE persistence are, to the extent described
by others in this thread, not by me. I just described a couple more
cases (and specifically one case) where it is bad that things are this
way (and cannot be solved by better design).

My point is: this doesn't happen _within_ single programs, but
everywhere there is even the slightest bit of communication there is a
chance of it happening.

Ole




 - C


 On Dec 16, 2005, at 6:40 AM, Jan-Ole Esleben wrote:

  Thanks; this is a problem we are well aware of. Our solution is to
  increase the amount of workers, obviously.
 
  However, I'm increasingly getting a feeling that for a rather big
  range of unlikely situations that are nonetheless to be expected, Zope
  doesn't work _at all_. In a WebServices setting, situations like the
  one I described, with one server calling back to another server within
  a call from that latter server and both not knowing anything about the
  implementation of the other, it would most certainly be extremely hard
  to foresee the exact setup of such situations and impossible to
  exclude them for persistent objects that actually _do_ change state
  (unlike mine). The solution is to not have state in your objects, and
  thus lose instantly most of what Zope is.
 
  However, as I see it, the problem is that what Zope actually _is_
  (i.e. mostly the ZODB) is an unhealthy way of coupling data and
  implementation (which is _exactly_ why my implementation didn't work
  immediately). This of course comes from its origins in TTW development
  where there wouldn't actually have been many user made products.
 
  Please tell me if I'm wrong with my assumption above, and why. I'm not
  trying to be inflamatory, this just has me really worried.
 
  Ole
 
 
  2005/12/15, Dieter Maurer [EMAIL PROTECTED]:
  Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100:
  Is it at all impossible to use XML-RPC _within_ a ZOPE architecture?
 
  In principle yes.
 
  Be careful however: it is easy to introduce deadlocks!
 
When during request processing you call back into the same
Zope via XML-RPC, the calling out request will not complete
until the XML-RPC returns a result (this always holds for
calls, XML-RPC or other, to an external or internal server).
 
Zope has a limited amount of workers (the default is 4) able
to execute requests. If there are no free workers, requests
have to wait for one.
 
Now imagine that as many requests arrive as there are workers
and each of them wants to perform an XML-RPC against the
same Zope. Then you have a deadlock: none of the XML-RPC requests
will finish, because there are no free workers. An no worker
will ever become free again, because each of them waits for
its XML-RPC to finish.
 
  Therefore, you should directly call internal resources (rather
  than use XML-RPC).
 
 
  --
  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 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] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Chris McDonough


On Dec 16, 2005, at 8:02 PM, Jan-Ole Esleben wrote:


I don't understand the problem.  How is using XML-RPC incompatible
with persistence?  What are you trying to exclude?


I'm sorry, but I don't understand _that_ question. What am I trying to
_exclude_?


You said:

 it would most certainly be extremely hard to foresee the exact  
setup of such situations and impossible to exclude them 



XML-RPC and (the concept of) persistence aren't incompatible. XML-RPC
(on a ZOPE server) and ZOPE persistence are, to the extent described
by others in this thread, not by me. I just described a couple more
cases (and specifically one case) where it is bad that things are this
way (and cannot be solved by better design).


AFAICT, people have told you to not use XML-RPC here and when you  
said it was not possible to avoid the use of XML-RPC, they provided  
suggestion about how to accomplish what you wanted anyway.  So I'm  
not sure what the exact problem is.



My point is: this doesn't happen _within_ single programs, but
everywhere there is even the slightest bit of communication there is a
chance of it happening.


The chance of what happening, sorry?  I'm still trying to understand  
the problem.  The only problem that was noted so far was a deadlock  
potential by Dieter which presumed you were doing XML-RPC requests to  
the same system which accepts them.  This is an unusual thing to do;  
it wouldn't happen under normal circumstances.


- 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 )


[Zope] hosting two site on one zope server

2005-12-16 Thread Allen Huang
I'm trying to host two site on one zope serverI have two fix IP and I have two network card installed.   I changed my zope.conf to include two http server that listen on two different ports.  But, I placed my site under different folder and I don't know how to redirect different IP to different folder sites by listening on the same port 80 (can change 8080 t0 80 on linux, don't know what server is already using this)can someone help me?__Do You Yahoo!?Tired of spam?  Yahoo! Mail has the best spam protection around http://mail.yahoo.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] hosting two site on one zope server

2005-12-16 Thread Tino Wildenhain
Am Freitag, den 16.12.2005, 17:28 -0800 schrieb Allen Huang:
 I'm trying to host two site on one zope server
  
 I have two fix IP and I have two network card installed. 
 I changed my zope.conf to include two http server that listen on two
 different ports.
 But, I placed my site under different folder and I don't know how to
 redirect different IP to different folder sites by listening on the
 same port 80 (can change 8080 t0 80 on linux, don't know what server
 is already using this)

If you going to provide some server services you should definitively
read a bit on that matter. Its not all that plug  play there.
Its not so hard either but still you can do harm to you and to others
with misconfigured servers connected to the internet.

In your specific case, you find out which daemon binds which port by
running:

netstat -lntp

as root will show you the process-ids and names of the programs.

I suspect it will be apache and you should better use it
in front of zope for all the complex rewriting you seem
to want. Look up documentation on VirtualHostMonster
to see how this (zero-config on zope) works.

Btw, if its just about hosting 2 IPs, you dont need 2 
network cards. You can assign any number of addresses
to a single card.

HTH
Tino Wildenhain


___
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] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
  I don't understand the problem.  How is using XML-RPC incompatible
  with persistence?  What are you trying to exclude?
  I'm sorry, but I don't understand _that_ question. What am I trying to
  _exclude_?
 You said:
  it would most certainly be extremely hard to foresee the exact
 setup of such situations and impossible to exclude them 

That's probably an idiomatic error on my part, sorry. I meant avoid
(in German, it's the same word).

 AFAICT, people have told you to not use XML-RPC here and when you
 said it was not possible to avoid the use of XML-RPC, they provided
 suggestion about how to accomplish what you wanted anyway.  So I'm
 not sure what the exact problem is.

The problem is a different one now, and I was referring to the
_reasons_ people had for telling me not to use XML-RPC. Part of the
problem I have now is that no application on the web is isolated from
others, and that ZOPE specifically _comes_ with XML-RPC capabilities
on the server's part.

  My point is: this doesn't happen _within_ single programs, but
  everywhere there is even the slightest bit of communication there is a
  chance of it happening.
 The chance of what happening, sorry?  I'm still trying to understand
 the problem.  The only problem that was noted so far was a deadlock
 potential by Dieter which presumed you were doing XML-RPC requests to
 the same system which accepts them.  This is an unusual thing to do;
 it wouldn't happen under normal circumstances.

The problem setup is this; I explained it above, but it this has
become a long thread:

I write a ZOPE product. I want to make use of other software on the
internet and the services that software provides. So I use the methods
exposed by that software via SOAP, XML-RPC, whatever.

One of those methods actually calls my product back, maybe because the
developer has learned that my product itself exposes some (or all) of
its functionality via XML-RPC. If this is all inside one call, which I
can't avoid explicitly as the developer of just my product, I have a
broken transaction on my hands that isn't easy to fix (and maybe
impossible). This holds true for the whole product, even if the method
called by the second server changed some completely unrelated data.

I hope that clears it up a little.

Ole
___
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] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Chris McDonough

The problem setup is this; I explained it above, but it this has
become a long thread:

I write a ZOPE product. I want to make use of other software on the
internet and the services that software provides. So I use the methods
exposed by that software via SOAP, XML-RPC, whatever.

One of those methods actually calls my product back, maybe because the
developer has learned that my product itself exposes some (or all) of
its functionality via XML-RPC. If this is all inside one call, which I
can't avoid explicitly as the developer of just my product, I have a
broken transaction on my hands that isn't easy to fix (and maybe
impossible). This holds true for the whole product, even if the method
called by the second server changed some completely unrelated data.


I see what you're saying, but how is this specific to Zope?  If you  
write a Perl program and expose it via mod_perl on Apache, and the  
program calls out to a service that calls back in to the mod_perl  
program (no matter how broken of a pattern this was), wouldn't the  
Apache process that was waiting on data be tied up in the same way?


- 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] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
It's not about the threads or processes being tied up and waiting,
it's about the transaction breaking: because the internal call (the
one from the second server back to the first) changes the object on
the first server, and thus when the first server checks wether the
object has changed after the transaction should close (during the last
return), it finds that indeed it has, and before it could write to it,
so it raises a conflict error invariably.

Ole


2005/12/17, Chris McDonough [EMAIL PROTECTED]:
  The problem setup is this; I explained it above, but it this has
  become a long thread:
 
  I write a ZOPE product. I want to make use of other software on the
  internet and the services that software provides. So I use the methods
  exposed by that software via SOAP, XML-RPC, whatever.
 
  One of those methods actually calls my product back, maybe because the
  developer has learned that my product itself exposes some (or all) of
  its functionality via XML-RPC. If this is all inside one call, which I
  can't avoid explicitly as the developer of just my product, I have a
  broken transaction on my hands that isn't easy to fix (and maybe
  impossible). This holds true for the whole product, even if the method
  called by the second server changed some completely unrelated data.

 I see what you're saying, but how is this specific to Zope?  If you
 write a Perl program and expose it via mod_perl on Apache, and the
 program calls out to a service that calls back in to the mod_perl
 program (no matter how broken of a pattern this was), wouldn't the
 Apache process that was waiting on data be tied up in the same way?

 - 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 )