RE: [Zope] 'Cannot Locate' errors from Bobo using pcgi...
-----Original Message----- From: Tony McDonald [mailto:tony.mcdonald@ncl.ac.uk] Sent: Monday, June 14, 1999 5:40 AM To: Zope List Cc: Alex Rice Subject: Re: [Zope] 'Cannot Locate' errors from Bobo using pcgi...
At 1:14 pm -0600 13/6/99, Alex Rice wrote:
On Sun, 13 Jun 1999 15:44:23 +0100, "Tony McDonald" <tony.mcdonald@ncl.ac.uk> said:
Tony> Bobo has encountered a problem publishing your object. Tony> Cannot locate object at: http://server.net/wip/squishdo
Unfortunately, this is normal. If you search the mailing list archives, you'll see the folks from DC agreed that there really should be hooks so Publisher can use standard_error_message or something nice instead of the Bobo traceback. Maybe that will show up in Zope2?
cheers Alex, but Ouch!! ... that's nasty. DC guys: Is there a fix for Zope1.10 that I can apply whilst waiting for Zope2? (it *is* fixed in Zope2 isn't it?)
Uhhmm... no. This problem is a bit more complex than it sounds. First off, a 'Not Found' error (404) comes about because what you're looking for is not in the object database, thus, the error is not raised *in* the object database, but in ZPublisher, the ORB (unlike, for example, a DTML error). Due to the (very intentional) modularity of ZPublisher, ZPublisher can't just assume that there is a standard_error_message object in the object database (you can use ZPublisher by itself without Zope) so imagine it raising a 404, looking for standard_error_message, which raises a 404 which... Furthermore, ZPublisher is protocol independent. If you wanted to write, say, an NNTP protocol extension to ZPublisher, you could publish your objects as newsgroups and items (sick!). Or IMAP, or XML-RPC (which Eric Kidd is working on as we speak) or CORBA, or whatever, pick your protocol. The problem is, standard_error_message doesn't make any sense in those contexts, or maybe it does? Jim has presented a proposal for fixing this, and a few other things about our error model, for example, if you impliment error handling in the ORB like his proposal, it will no longer be necesary for the object database to grab its own errors, it can just let them float up to the ORB and then use the new method to find and call standard_error_message. This could be a 2.0 feature, if we can find the resources (I beg of you to volunteer ;). -Michel
tone. ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
Thanks for the reply Michel, but now I'm confused (no change there then).
cheers Alex, but Ouch!! ... that's nasty. DC guys: Is there a fix for Zope1.10 that I can apply whilst waiting for Zope2? (it *is* fixed in Zope2 isn't it?)
Uhhmm... no. This problem is a bit more complex than it sounds. First off, a 'Not Found' error (404) comes about because what you're looking for is not in the object database, thus, the error is not raised *in* the object database, but in ZPublisher, the ORB (unlike, for example, a DTML error).
[snip] I notice that Zope.org doesn't have this problem, is it running ZopeHTTPServer then? (surely not).
This could be a 2.0 feature, if we can find the resources (I beg of you to volunteer ;).
-Michel
I wish I were that good! (only written three external methods so far, and no products). For now, I want to be able to contribute with snippets of DTML, and little anecdotes about when the 'lightbulb' went on so as to get more Zopistas on board. As to the hard core stuff, I've been Python-programming for about 2 months on-and-off - ie, do your *really* want to give a CVS account? :) (don't - I'm not there yet...) ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
participants (2)
-
Michel Pelletier -
Tony McDonald