- Zope-Dev - Zope lists

Prevayler and "Object Prevalence"
by John Ziniti 04 Mar '03

04 Mar '03

Any ZODB developers read this article at /. and the accompanying one at developerWorks? Would anyone care to comment about the relevance/comparisons of "prevalence" to the concepts of persistence used in ZODB and/or ZEO? http://developers.slashdot.org/article.pl?sid=03/03/03/1220222&mode=nested&… Just looking for some info. Thanks in advance, JZ

3 2

HTTP Response headers in ZPublisher.HTTPResponse
by Romain Slootmaekers 03 Mar '03

03 Mar '03

Yo, the response headers set in ZPublisher.HTTPResponse our not always RFC compliant. In case of exceptions you get: (round lines 670 in HTTPResponse.py) if ev.find( '<html>') >= 0: ev = 'bobo exception' self.setHeader('bobo-exception-value', ev[:255]) If the content is a xml,wml,whtml,... page, this results in exception headers like: Bobo-Exception-Value: <?xml version="1.0"?> <!DOCTYPE ... while most browsers will not barf on this, we encountered numerous problems with wap-gateways refusing to swallow this. Another question is whether it is wise to send things like the file and line numbers where the exception took place to the client. I can understand that it can be useful in debug mode, but I can't see a reason to do this in a production setup. The simplest way of fixing this is to change the code to something like: ev = 'bobo exception' self.setHeader('bobo-exception-value', ev) or to leave out these headers altogether. Romain.

1 0

Re: [ZODB-Dev] standalone ZODB for large Numeric arrays
by Mike Mueller 03 Mar '03

03 Mar '03

>> >>AFAICT, AdaptableStorage is designed to allow this kind of thing. >>Shane? Sounds interesting. I am going to search for this. >Yes, it is. I don't know anything about NetCDF, but it sounds >intriguing. I guess NetCDF is not just an encoding format, but also some >kind of database for large arrays. > >Shane http://my.unidata.ucar.edu/content/software/netcdf/index.html NetCDF (network Common Data Form) is an interface for array-oriented data access and a library that provides an implementation of the interface. The netCDF library also defines a machine-independent format for representing scientific data. Together, the interface, library, and format support the creation, access, and sharing of scientific data. Python interface is contained in Konrad Hinsens Scientifc package http://starship.python.net/~hinsen/ScientificPython/ Mike

1 0

emacs/pdbtrack users - enhanced to handle Zope's "Script (Python)"
by Ken Manheimer 03 Mar '03

03 Mar '03

For those of you that use emacs and pdbtrack, i've extended it a bit to be useful with non-local scripts - eg, through-the-web python scripts, or filesystem-based code on the server's filesystem, hence not findable in your filesystem at the compiled-in path. Pdbtrack is part of emacs python-mode which displays the source file and indicates the current line as you step through the code with the python debugger, pdb, in an emacs shell buffer. It uses information in the pdb trace to find the file and the line, but couldn't do anything if the path of the file isn't valid on your system - eg if the script was compiled on a different system, with the source in a different place or noexistent on your system, or if there is no valid path for the script, eg through-the-web scripts. With the changes, when pdbtrack can't find the file at the indicated path, it tries to find it in existing buffers. It uses the function name and looks through the buffers in your emacs session, from most to least recent, looking for a python-mode buffer that either is named for the function or has a definition (def or class) for that function. So to get source tracking for code that's not resident in your filesystem, you put a copy of the script in a buffer, and pdbtrack will find it. (It also allows an offset for the leading '##' meta-comment lines in filesystem copies of python scripts.) You can find the new version at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Misc/… It's pretty fresh - i'd be happy if people would give it a try, and let me know if you hit problems with it. -- Ken Manheimer klm(a)zope.com

1 1

ZPublisher XMLRPC extension for user exceptions (II)
by Illarramendi Amilibia, Aitor 28 Feb '03

28 Feb '03

Hello everybody: I hope I've send it in the proper format this time :) I apologize for the first post I made, that was the corporative mail tool that automated all the e-mail... I'm making some kind of development related to invoke externally from a Java Applet some ZOPE product methods via XML-RPC. I use ZOPE as the XMLRPC server, as it can 'listen' for XMLRPC requests, find the method requested using URL and traversal, invoke the method and receive the return value of it and then encapsulate the result in a XMLRPC response. Anyways, I want to report some exceptions from my ZOPE product python methods through XML-RPC to the applet. As my methods don't work directly with XMLRPC, all is embedded inside ZOPE, all the XMLRPC works are transparent for my python methods, so I didn't realize how I could do it. After looking for the ZOPE code responsible of the XMLRPC request process and XMLRPC response generation I found that some of the work was being done in ZPublisher xmlrpc.py code (Response stuff). Then when I started to read the comments of the code I found this in the Response class of the code: """ It's probably possible to improve the 'exception' method quite a bit. The current implementation, however, should suffice for now. """ But as you will see is not enough, at least for my needs. I want to define my own exceptions in my product, this exceptions could be defined as follows: class MyOwnException: __init__(self, faultCode, faultString): self.faultCode = faultCode self.faultString = faultString Obviously I want to map XMLRPC-like fault format. Then, I could raise this exception from my method, and I will want that the class responsible of making the XMLRPC Response for my XMLRPC client will use it for composing the XML for XMLRPC using my fault code and fault string. But I found that xmlrpc.py doesn't take into account that (i'm talking of ZOPE 2.6.0) so i had to make some changes in the code of ZPublisher/xmlrpc.py: def exception(self, fatal=0, info=None, absuri_match=None, tag_search=None): # Fetch our exception info. t is type, v is value and tb is the # traceback object. if type(info) is type(()) and len(info)==3: t,v,tb = info else: t,v,tb = sys.exc_info() # Don't mask 404 respnses, as some XML-RPC libraries rely on the HTTP # mechanisms for detecting when authentication is required. Fixes Zope # Collector issue 525. if t == 'Unauthorized' or (isinstance(t, types.ClassType) and issubclass(t, Unauthorized)): return self._real.exception(fatal=fatal, info=info) # Create an appropriate Fault object. Containing error information Fault=xmlrpclib.Fault f=None try: # Strip HTML tags from the error value v = str(v) remove = [r"<[^<>]*>", r"&[A-Za-z]+;"] for pat in remove: v = re.sub(pat, " ", v) from Globals import DevelopmentMode if DevelopmentMode: from traceback import format_exception value = '\n' + ''.join(format_exception(t, v, tb)) else: value = '%s - %s' % (t, v) ###### my own extension for catching user exceptions START ##### try: faultCode = getattr(sys.exc_info()[1],'faultCode') faultString = getattr(sys.exc_info()[1],'faultString') except: print "no according exception type" ###### my own extension for catching user exceptions FINISH ##### if isinstance(v, Fault): f=v ###### my own extension for catching user exceptions START ##### elif (faultCode and faultString) : f = xmlrpclib.Fault(faultCode,faultString) ###### my own extension for catching user exceptions FINISH ###### elif isinstance(v, Exception): f=Fault(-1, 'Unexpected Zope exception: %s' % value) else: f=Fault(-2, 'Unexpected Zope error value: %s' % value) except: f=Fault(-3, "Unknown Zope fault type") # Do the damage. self.setBody(f) self._real.setStatus(200) return tb By that way, I could send my own fault code and fault descriptions via XML-RPC. But as you can see, I have to extend ZOPE code, and I don't want to do it, I have to work with standard releases of ZOPE. Do you think that something like that would be improved in an early future for next ZOPE releases? Any opinion will be really appreciated. Thanks for advance. Regards. Aitor Illarramendi Amilibia Ingeniero de software Mando y Control Carretera de Loeches, 9 28850 - Torrejón de Ardoz, Madrid (ESPAÑA) Tel: +34-91-626.80.60 Fax: +34-91-626.81.14 aillarramendi(a)indra.es www.indra.es

3 2

Index errors revisited: KeywordIndex unindex_object could not remove documentId -883140122 from index ComponentVersions. This should not happen.
by Jean Jordaan 28 Feb '03

28 Feb '03

Hi all We've posted about this before, but never managed to pin down the issue nicely. It doesn't interfere with our application, as far as we could tell, so we've let it slide. Here's another attempt at formulating the problem. We run a script which iterates over 719 <ZClass License> instances. For each instance, either one or two <ZClass Reminder> instances are created and edited. The script completes, logging all the way: 2003-02-27T09:43:44 INFO(0) MyDebugLog recreate_reminders> INFO: creating reminders for License_99 Then, Zope starts spitting out 657 errors like the following: 2003-02-27T09:43:49 ERROR(200) KeywordIndex unindex_object could not remove documentId -883140119 from index ComponentVersions. This should not happen. Traceback (innermost last): File /usr/local/zope/2-5-1/lib/python/Products/PluginIndexes/common/UnIndex.py, line 168, in removeForwardIndexEntry (Object: ComponentVersions) KeyError: -883140119 Most of these errors are identical. There are 172 unique errors, the rest are all retries. The 172 keys are not in the catalog. The only indexes involved are ComponentVersions and NodeNames, both 'lines' properties of <ZClass Reminder>. Does anyone know how to cause this, so that I can stop doing it? I'm trying to narrow it down again .. (Zope 2.5.1 (source release, python 2.1, linux2), python 2.1.3, linux2) -- Jean Jordaan http://www.upfrontsystems.co.za

4 5

RE: [Zope-dev] ZPublisher XMLRPC extension for user exceptions
by Illarramendi Amilibia, Aitor 28 Feb '03

28 Feb '03

Ok. I'm sorry, I'll send it again in the proper format. Regards. -----Mensaje original----- De: Dieter Maurer [mailto:dieter@handshake.de] Enviado el: jueves 27 de febrero de 2003 20:20 Para: Illarramendi Amilibia, Aitor Asunto: Re: [Zope-dev] ZPublisher XMLRPC extension for user exceptions You should not post HTML message to this mailing list. You should not attach images to mails send to technical mailing lists. Large posts (yours is larger than 30 kB) are rarely read. I discarded your message without any attempt to read it... Dieter

1 0

ZPublisher XMLRPC extension for user exceptions
by Illarramendi Amilibia, Aitor 27 Feb '03

27 Feb '03

Hello everybody: I'm making some kind of development related to invoke externally from a Java Applet some ZOPE product methods via XML-RPC. I use ZOPE as the XMLRPC server, as it can 'listen' for XMLRPC requests, find the method requested using URL and traversal, invoke the method and receive the return value of it and then encapsulate the result in a XMLRPC response. Anyways, I want to report some exceptions from my ZOPE product python methods through XML-RPC to the applet. As my methods don't work directly with XMLRPC, all is embedded inside ZOPE, all the XMLRPC works are transparent for my python methods, so I didn't realize how I could do it. After looking for the ZOPE code responsible of the XMLRPC request process and XMLRPC response generation I found that some of the work was being done in ZPublisher xmlrpc.py code (Response stuff). Then when I started to read the comments of the code I found this in the Response class of the code: """ It's probably possible to improve the 'exception' method quite a bit. The current implementation, however, should suffice for now. """ But as you will see is not enough, at least for my needs. I want to define my own exceptions in my product, this exceptions could be defined as follows: class MyOwnException: __init__(self, faultCode, faultString): self.faultCode = faultCode self.faultString = faultString Obviously I want to map XMLRPC-like fault format. Then, I could raise this exception from my method, and I will want that the class responsible of making the XMLRPC Response for my XMLRPC client will use it for composing the XML for XMLRPC using my fault code and fault string. But I found that xmlrpc.py doesn't take into account that (i'm talking of ZOPE 2.6.0) so i had to make some changes in the code of ZPublisher/xmlrpc.py: def exception(self, fatal=0, info=None, absuri_match=None, tag_search=None): # Fetch our exception info. t is type, v is value and tb is the # traceback object. if type(info) is type(()) and len(info)==3: t,v,tb = info else: t,v,tb = sys.exc_info() # Don't mask 404 respnses, as some XML-RPC libraries rely on the HTTP # mechanisms for detecting when authentication is required. Fixes Zope # Collector issue 525. if t == 'Unauthorized' or (isinstance(t, types.ClassType) and issubclass(t, Unauthorized)): return self._real.exception(fatal=fatal, info=info) # Create an appropriate Fault object. Containing error information Fault=xmlrpclib.Fault f=None try: # Strip HTML tags from the error value v = str(v) remove = [r"<[^<>]*>", r"&[A-Za-z]+;"] for pat in remove: v = re.sub(pat, " ", v) from Globals import DevelopmentMode if DevelopmentMode: from traceback import format_exception value = '\n' + ''.join(format_exception(t, v, tb)) else: value = '%s - %s' % (t, v) ###### my own extension for catching user exceptions START ##### try: faultCode = getattr(sys.exc_info()[1],'faultCode') faultString = getattr(sys.exc_info()[1],'faultString') except: print "no according exception type" ###### my own extension for catching user exceptions FINISH ##### if isinstance(v, Fault): f=v ###### my own extension for catching user exceptions START ##### elif (faultCode and faultString) : f = xmlrpclib.Fault(faultCode,faultString) ###### my own extension for catching user exceptions FINISH ###### elif isinstance(v, Exception): f=Fault(-1, 'Unexpected Zope exception: %s' % value) else: f=Fault(-2, 'Unexpected Zope error value: %s' % value) except: f=Fault(-3, "Unknown Zope fault type") # Do the damage. self.setBody(f) self._real.setStatus(200) return tb By that way, I could send my own fault code and fault descriptions via XML-RPC. But as you can see, I have to extend ZOPE code, and I don't want to do it, I have to work with standard releases of ZOPE. Do you think that something like that would be improved in an early future for next ZOPE releases? Any opinion will be really appreciated. Thanks for advance. Regards. Aitor Illarramendi Amilibia Ingeniero de software Mando y Control <http://www.indra.es/> Indra.bmp Carretera de Loeches, 9 28850 - Torrejón de Ardoz, Madrid (ESPAÑA) Tel: +34-91-626.80.60 Fax: +34-91-626.81.14 aillarramendi(a)indra.es www.indra.es <http://www.indra.es/>

1 0

Session Event Listeners
by Beef a 27 Feb '03

27 Feb '03

Does anyone have any idea how to register session event listeners in Zope 2? This is a standard concept in Java/JSP/ASP et al. Basically it allows a method to be registered and executed when a http session is either created, lost or invalidated. Is there such a thing in Zope? Thanks -- Brian _________________________________________________________________ Express yourself with cool emoticons http://messenger.msn.co.uk

3 2

Following the Zope Collector
by Florent Guillaume 26 Feb '03

26 Feb '03

Hi, Currently the Zope collector is in "dispatcher On" mode, whereas the CMF and Zope3 collectors have "dispatcher Off". The difference, for those not familiar with Collector configuration, is that with dipatcher On only the few collector managers are notified by email of new issues in the collector (and are theoretically responsible for assigning them to Supporters), whereas in Off mode all the supporters receive the notification. As a supporter, I find that receiving a notification for each new issue is invaluable in tracking what the current problems are, and in having good response time on "easy" bugs. This works very well for the CMF collector, and I'm sure the Zope3 folks wouldn't want it any other way either. But currently I've no idea what's happening to the Zope collector unless I browse every entry on a regular basis to see what may have changed, which is very time consuming and impractical considering the number of entries. So I'd like to propose to switch the Zope collector to "dispatcher Off". This would mean more email traffic for the supporters, but it's easy enough to filter and I think the benefits are worth it. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

3 3