- Zope-Dev - Zope lists

Corrupted database, ZopeHTTPServer won't start
by Martin Dougiamas 26 May '99

26 May '99

Oh no! My 1.10.2 Zope server (Redhat 6.0) had to be hard-booted (keyboard lockup) and so the Zope server never got a chance to close nicely. Now I can't start ZopeHTTPServer at all! :-( var/serve.errors contains just this: Traceback (innermost last): File "serve.py", line 92, in ? ZopeHTTPServer.main(args) File "ZopeHTTPServer/ZopeHTTPServer.py", line 498, in main start(module_file,host,port,threading,env) File "ZopeHTTPServer/ZopeHTTPServer.py", line 436, in start set_published_module(module_file,BoboRequestHandler,env) File "ZopeHTTPServer/ZopeHTTPServer.py", line 432, in set_published_module __import__(name) # to catch problem modules right away File "lib/python/Main.py", line 103, in ? Bobobase=OFS.Application.open_bobobase() File "lib/python/OFS/Application.py", line 319, in open_bobobase Bobobase=Globals.Bobobase=Globals.PickleDictionary( File "lib/python/BoboPOS/PickleDictionary.py", line 159, in __init__ db=apply(DBType,(),storage_options) File "lib/python/BoboPOS/SimpleDB.py", line 221, in __init__ self.open(file_name,create,revision_time,meta_index,read_only) File "lib/python/BoboPOS/SimpleDB.py", line 287, in open try: self.index,self.pos=read_index( File "lib/python/BoboPOS/SimpleDB.py", line 1365, in read_index raise DatabaseError, ('Corrupted data record at %s' % pos) DatabaseError: Corrupted data record at 3111549 What can I do? I need to get that data back. -- ### Martin Dougiamas -- Internet Agent "...The Eighties, ### Centre for Educational Advancement the Nineties, ### http://cea.curtin.edu/staff/martin the Naughties."

3 2

RE: [Zope-dev] y2k
by Brian Lloyd 26 May '99

26 May '99

> Thanks for the patch, BTW. I think your our number #1 patch > contributor, but sometimes I get all these Martijns mixed up. > Your both > cool! ;) > > BTW, a successful way Mike Pelletier and I have avoided > confusion is to > keep our first names different. People seem to think in > terms of first > names, especially on lists, so calling myself Michel and he calling > himself Mike has helped (I think, at least I don't get confused about > who I am anymore). So maybe one of you guys could go by a nickname? > Just a suggestion, there isn't really a big issue here. > > -(yes-my-name-is-really-spelled)Michel Hmm - if the Zope community keeps growing like this, we're going have to start using UUIDs instead of names... ;^) eee0dcd4-1dd1-11b2-a7ec-85f3369699b4 brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

RE: [Zope-dev] y2k
by Michel Pelletier 26 May '99

26 May '99

> -----Original Message----- > From: Martijn Pieters [mailto:mj@antraciet.nl] > Sent: Wednesday, May 26, 1999 5:54 AM > To: Rod.; zope-dev(a)zope.org > Subject: Re: [Zope-dev] y2k > > > At 09:42 22/05/99 , Rod. wrote: > >heyas :) > > > >I hope this is the right place to ask.. a thousand apologies > in advance if > >it isnt! > >My workplace uses Zope quite heavily for internal database work, and > >management wants to know if its y2k compliant. > > > >I assumed it was (being so clevery designed, with a modern > language like > >python) but an official thumbs up from someone > >who is familliar with its internals would be most appreciated. > > > >Thankyou in advance, > > > >Rod. > > I (and others) have found 1 Y2K bug (of a sort) in Zope 1.10.2 (and > possibly earlier). The problem has not yet been solved in versions > 1.11.0pr1 and 2.0.0.a1. > > Zope uses cookies to make the size of editing windows in DTML > Methods/Documents and SQL Methods persistent. > > These cookies are hardwired to expire on the change of the > millenium, and > will not be returned by your browser in the year 2000 and > later. This is > just a minor inconvenience, Zope will cntinue to work if your > server does, > see comments by others. > > Here are two patches that solve these problems. They were made using > version 1.10.2, but probably work on other versions. YMMV. > They solve the > problem by relating the expiring date of the cookie to the > current date. > Cookies now will expire one year after they have been set. > I believe Brian checked these changes in earlier today. Thanks for the patch, BTW. I think your our number #1 patch contributor, but sometimes I get all these Martijns mixed up. Your both cool! ;) BTW, a successful way Mike Pelletier and I have avoided confusion is to keep our first names different. People seem to think in terms of first names, especially on lists, so calling myself Michel and he calling himself Mike has helped (I think, at least I don't get confused about who I am anymore). So maybe one of you guys could go by a nickname? Just a suggestion, there isn't really a big issue here. -(yes-my-name-is-really-spelled)Michel

1 0

Strange exception in ZServer/medusa/asynchat.py
by Skip Montanaro 26 May '99

26 May '99

I'm using Medusa by way of Zope's ZServer. I have ZServer sitting behind an Apache proxy and am bombing it from a threaded client script that reads a web server log file as input and throws requests at the Apache server. I can vary the number of threads to adjust the load. I normally run it with five simultaneous threads. By default, the system runs briefly then (as they say), "Whammo! Blammo!", I get the following error: Unhandled exception in thread: Traceback (innermost last): File "/home/dolphin/skip/src/Zope/ZServer/PubCore/ZServerPublisher.py", line 97, in __init__ response._finish() File "/home/dolphin/skip/src/Zope/ZServer/HTTPResponse.py", line 209, in _finish self.stdout.close() File "/home/dolphin/skip/src/Zope/ZServer/HTTPResponse.py", line 235, in close self._channel.push(CallbackProducer(self._channel.done)) File "/home/dolphin/skip/src/Zope/ZServer/HTTPServer.py", line 307, in push if send: self.initiate_send() File "/home/dolphin/skip/src/Zope/ZServer/medusa/asynchat.py", line 200, in initiate_send self.refill_buffer() File "/home/dolphin/skip/src/Zope/ZServer/medusa/asynchat.py", line 184, in refill_buffer self.producer_fifo.pop() File "/home/dolphin/skip/src/Zope/ZServer/medusa/asynchat.py", line 255, in pop del self.list[0] IndexError: list assignment index out of range If you look at the code in asynchat.fifo.pop, the error can only be explained by the fact that two threads are modifying the fifo simultaneously, since access to self.list[0] succeeded in the statement before the statement that throws the IndexError: def pop (self): if self.list: result = (1, self.list[0]) # non-null list here del self.list[0] # empty list here else: result = (0, None) return result I modified the fifo class to lock access to its list: class fifo: def __init__ (self, list=None): self.lock = thread.allocate_lock() self.lock.acquire() if not list: self.list = [] else: self.list = list self.lock.release() def __len__ (self): self.lock.acquire() l = len(self.list) self.lock.release() return l def first (self): self.lock.acquire() item = self.list[0] self.lock.release() return item def push (self, data): self.lock.acquire() self.list.append (data) self.lock.release() def pop (self): self.lock.acquire() if self.list: result = (1, self.list[0]) del self.list[0] else: result = (0, None) self.lock.release() return result but this didn't help: Unhandled exception in thread: Traceback (innermost last): File "/home/dolphin/skip/src/Zope/ZServer/PubCore/ZServerPublisher.py", line 97, in __init__ response._finish() File "/home/dolphin/skip/src/Zope/ZServer/HTTPResponse.py", line 209, in _finish self.stdout.close() File "/home/dolphin/skip/src/Zope/ZServer/HTTPResponse.py", line 235, in close self._channel.push(CallbackProducer(self._channel.done)) File "/home/dolphin/skip/src/Zope/ZServer/HTTPServer.py", line 307, in push if send: self.initiate_send() File "/home/dolphin/skip/src/Zope/ZServer/medusa/asynchat.py", line 200, in initiate_send self.refill_buffer() File "/home/dolphin/skip/src/Zope/ZServer/medusa/asynchat.py", line 175, in refill_buffer p = self.producer_fifo.first() File "/home/dolphin/skip/src/Zope/ZServer/medusa/asynchat.py", line 254, in first item = self.list[0] IndexError: list index out of range This error also looks like a threading problem. When refill_buffer tests self.producer.fifo, it sees something, but by the time it calls fifo.first, the list has evaporated: while 1: if len(self.producer_fifo): # non-null list here p = self.producer_fifo.first() # null list here Any ideas? Is there a way to easily turn off threading? It seems that the data structures are not properly protected. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip(a)mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583

2 1

y2k
by Rod. 26 May '99

26 May '99

heyas :) I hope this is the right place to ask.. a thousand apologies in advance if it isnt! My workplace uses Zope quite heavily for internal database work, and management wants to know if its y2k compliant. I assumed it was (being so clevery designed, with a modern language like python) but an official thumbs up from someone who is familliar with its internals would be most appreciated. Thankyou in advance, Rod. ~^~~~^~~~^~~~^~~~^~~~~^^^~~~~~~~~~~~~~~~~~~^^^~~'`'- Rod Palmer is a connect.com.au development thing-amy. bwarff(a)connect.com.au +61 3 9251 3650 ~^~~~^~~~^~~~^~~~^~~~~^^^~~~~~~~~~~~~~~~`'-....

4 3

(bug/Zope 1.11.0pr1) Content-Type header from a DTML Method/Document are ignored
by Service Informatique CHSR 25 May '99

25 May '99

Hello, Zope 1.11.0 seems to ignore Content-Type headers Let 'dm' be this DTML Method: {\rtf1\ansi ....} Of course, .... is the rest of the rtf document. Note that it is dynamicly generated. This is why I need to use a DTML Method to render the RTF document. Under Zope 1.10.2, dm renders nicely (Word is launched and the RTF document is seen directly in the browser from IE 3.x. From Navigator 4.5, I can either save or open the document). However, under Zope 1.11.0pr1, IE 3.x says it can't open the document. At the end of the document is what ZServer displays. However, there is no error with Navigator, but it displays the RTF file as text. A freshly-installed-from-source-Zope 1.11.0pr1 exhibits the same behavior. What ZServer prints: uncaptured python exception, closing channel <zhttp_channel connected 160.0.108.48:1944 at 84d15b8 channel#: 84 requests:1> (socket.error:(9, 'Mauvais descripteur de fichier.') [/home/webdevel/devel/11.0/Zope/ZServer/medusa/asynchat.py|initiate_send|204 ] [/home/webdevel/devel/11.0/Zope/ZServer/medusa/http_server.py|send|386] [/home/webdevel/devel/11.0/Zope/ZServer/medusa/asyncore.py|send|233] ) Can someone post this to the Collector for me? Regards, Jephte CLAIN Service Informatique CHSR

1 0

Problem writing user folder
by Alexander Staubo 25 May '99

25 May '99

In writing my NT domain authentication folder, I'm having some problems deriving a new user folder product. Everything works, _except_ Zope refuses to authorize the user, even though the authentication technically succeeds; I see that object traversal accepts the user, but it's Zope's document rendering thing that denied the authorization. The problem seems to boil down to a problem with BasicUser and its allowed() method. If I override BasicUser's allowed() method (which is aliased as "hasRole") and explicitly return 1, no problem. What's weird is that Zope's implementation of BasicUser.allowed() actually raises an exception, and this is the reason that it does not validate the role: Traceback (innermost last): File "\tools\zope\lib\python\AccessControl\User.py", line 204, in allowed if not parent.aq_inContextOf(self.aq_parent.aq_parent,1): AttributeError: aq_inContextOf It's the damndest thing. I'm thinking perhaps my user instance is acquisition-crippled, but my folder's validate() method _is_ doing this: User = User.__of__(self) ... return User If it's of any relevance, I've used the etcFolderUser product as a template. I'm sure it's pretty simple. If need be I can send the actual code. -- Alexander Staubo http://www.mop.no/~alex/ "Give me an underground laboratory, half a dozen atom smashers and a beautiful girl in a diaphanous veil waiting to be turned into a chimpanzee, and I care not who writes the nation's laws." --S. J. Perelman

1 0

Calendar tag and MS-Access Database fails on date type
by Brad Clements 25 May '99

25 May '99

I'm using the contributed Calendar product and trying to lookup records from an MS-Access database, but I'm having trouble getting calendar's date variable to work correctly with the SQL Method. I've tried all iterations in the SQL method, having the target date be passed as a type 'date', or type 'string', and/or using PrincipiaTime() (when passed as a string), No matter which way I try, I either get all records in my database, or an error in PrincipiaTime or an error in DA.py. I even managed to corrupt an SQL method some how such that all operations on it fail with Error, exceptions.AttributeError: self (weird, eh). So that particular method got renamed to *.old and I moved on. Anyway, has anyone gotten Calendar to work with an SQL Method? My curent test form looks like this:    <br>      You can see that I'm trying to force "date" to be a string type when passed to CalendarLookup (that's just this particular iteration). One comment, although mode='week', Calendar still shows it as a month view to start with when I "view" it. My current SQL Method CalendarLookup is like this (yes, its complicated): Args: identifier:string="" city:string="" county:list:string="" region:string="" unapproved:string="" date:string="" select * from [Calendar]                DateValue(StartDateTime) >= DateValue()   DateValue(EndDateTime) <= DateValue()   order by StartDateTime asc DateValue is an MS-Access SQL function that converts the passed in arg to just a date serial value. It can take a string or a date. If the date has a time, it removes it. For some reason, this particular setup returns all records in the database for EVERY DAY. If I change args to date:date, and DateValue() to just   StartDateTime >=    EndDateTime <=  I get this: Error, exceptions.TypeError: __div__ nor __rdiv__ defined for these operands Any ideas? Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937

1 0

RE: [Zope-dev] A product class that subclasses another product
by Michel Pelletier 24 May '99

24 May '99

> -----Original Message----- > From: Itai Tavor [mailto:itavor@vic.bigpond.net.au] > Sent: Wednesday, May 19, 1999 11:10 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] A product class that subclasses another product > > > Hi, > > I'm building several products that need to share several > common attributes > and methods, so I put those is a product ('Master') that the > other products > subclass. > > My problem is that I can't figure out how to call methods in > the Master > class and how to access its attributes. > > Very simplified, it looks something like this: > > class Master: > > def __init__(self, status, REQUEST=None): > """Initialize a new master object""" > self.status = status > > def manage_edit(self, status, REQUEST=None): > """Change object properties""" > self.status = status > > def Visible(self): > """Check if object's status is 'visible'""" > if self.status == 4: > return 1 > return 0 > > > from Products.Master import Master > class Foo(Master): > > meta_type = 'Foo' > id = '' > icon = 'misc_/Foo/icon' > > def __init__(self, id, title, status, REQUEST): > """Create a new article entry""" > self.id = id > self.title = title > Master(status, REQUEST) > > def manage_edit(self, title, status, REQUEST=None): > """Change information for object""" > self.title = title > Master.manage_edit(status, REQUEST) > > > The above simply fails to find the Master methods. I tried > Master.Master.manage_edit, as well as doing self.master = > Master(status, > REQUEST) in __init__ and then master.manage_edit(...), but > neither worked. > Also, is it possible to access attributes of the Master > class, or do I need > to define methods in Master to return attributes? > Your question could best be answered on the Python mailing list, as this is a Python question (in the context of Zope). I suspect Computed attributes could help you out here in ExtensionClasses, but there may be a Python mechanism I am unaware of that can solve the problem without using Computed attributes. The Python list can be found at http://www.python.org -Michel > Thanks > Itai Tavor > -- > Itai Tavor -- "Je sautille, donc je suis." -- > itavor(a)vic.bigpond.net.au -- - Kermit the Frog -- > -- -- > -- "Every day, once a day, give yourself a present" - Dale Cooper -- > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (For non-developer, user-level issues, use the companion list, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

2 1

enhanced pcgi_publisher.py
by Jeff Bauer 23 May '99

23 May '99

Hi everyone. With the availability of Zope2 alpha I'd like to take an opportunity to dust off a version of pcgi_publisher I worked on last December. I withdrew it after the initial Zope release because too many things were changing too quickly. Since then, Digital Creations has released PCGIServer, which works between pcgi-wrapper and Medusa. This is especially handy for connecting to Zope through your web server. However, I have other reasons for wanting to maintain (and even extend) pcgi_publisher. The reasons are related to legacy projects and other projects in which I prefer to allocate one long running process (LRP) per session. After reviewing my earlier notes, here is list of proposed enhancements: 1. Added support for concurrency (PCGI_THREAD_POOL directive) by using standard Python module SocketServer. Guido accepted a slight patch to the SocketServer module that I submitted prior to the Python 1.5.2 final. 2. Added ability to launch processes manually by passing it the pathname of the pcgi info file. 3. Applied fixes suggested by Digital Creations. 4. Inactivity timer: shuts down the process after a designated value is exceeded. Item 2 becomes less important as we move process launch control outside of PCGI, but it's still useful for testing, perhaps. Item 4 is handy for some of my projects, where I might allocate one process per session. Other Zopists may find it useful. If there are no objections, I'll try to have a new version ready soon. It could possibly be added to the Zope contribution area or bundled with the next alpha/beta release. Everything should be backwards compatible with prior versions of pcgi_publisher, with the possible/conditional exception of items discussed below: 1. Starting around line 164 we have a try/except block to catch import errors: try: from ZPublisher import publish_module except ImportError: try: from cgi_module_publisher import publish_module except ImportError: return self.fatalError( "unable to import publish_module from ZPublisher") Is there any reason to continue to check for cgi_module_publisher? 2. initPrincipia() -- is this still used by anyone? 3. PCGI_WORKING_DIR has been deprecated for over a year now. Is anyone using it? Finally, I'm aware there are other features/fixes/requests that ought to be addressed with pcgi: - out-of-band communications - process launch - data streaming - mod_pcgi The enchanced pcgi_publisher will do nothing to address these issues <0.7 wink> but they haven't been forgotten. Best regards, Jeff Bauer Rubicon, Inc.

1 0