Re: [Zope-dev] Logging of ConflictError
Hi Florent, Damn, I was working on this at the same time :-S Florent Guillaume wrote: I've improved the logging of ConflictError in Zope 2.9 and trunk. http://svn.zope.org/?rev=40454view=rev Now you'll get two things: - logs at level BLATHER for each conflict, but it may be retried - log at level ERROR when the conflict can't be retried anymore and is returned to the browser as an error. In my work, I've actually changed this to use the new, proper logging calls. I'll be comitting later this morning. I removed the log at level INFO because it is very misleading for system administrators in my experience. I don't think so, I've actually changed and enhanced this in my work. You now get a log at INFO whenever a conflict occurs. It includes more information than the old version, as you'll see... Do people want this also for 2.8? Note that it changes the log format, so may break third party tools that parse logs. I was planning on rolling my changes out to 2.8, 2.9 and the trunk. Unless anyone strenuously objects, I still intend to do that. I cleaned up a lot of the code and made a few other changes that generally improve logging. It's a shame Florent and I were genuinely working on this at the same time without the other knowing... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope tests: 8 OK
Summary of messages to the zope-tests list. Period Thu Dec 1 12:01:02 2005 UTC to Fri Dec 2 12:01:02 2005 UTC. There were 8 messages: 8 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:15:43 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003690.html Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:17:13 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003691.html Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:18:44 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003692.html Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:20:14 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003693.html Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:21:44 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003694.html Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:23:14 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003695.html Subject: OK : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:24:44 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003696.html Subject: OK : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Thu Dec 1 22:26:14 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003697.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On 2 Dec 2005, at 11:09, Chris Withers wrote: Damn, I was working on this at the same time :-S Florent Guillaume wrote: I've improved the logging of ConflictError in Zope 2.9 and trunk. http://svn.zope.org/?rev=40454view=rev Now you'll get two things: - logs at level BLATHER for each conflict, but it may be retried - log at level ERROR when the conflict can't be retried anymore and is returned to the browser as an error. In my work, I've actually changed this to use the new, proper logging calls. I'll be comitting later this morning. It doesn't really matter, zLOG has a compatibility layer that ends up doing the same thing. I removed the log at level INFO because it is very misleading for system administrators in my experience. I don't think so, I've actually changed and enhanced this in my work. You now get a log at INFO whenever a conflict occurs. It includes more information than the old version, as you'll see... Please no. Don't put anything at INFO. A conflict error is either something normal that should be at level BLATHER or below, or an ERROR that a sysadmin wants to see logged as such. INFO sucks for recurring stuff like that that in addition contain the word error which it isn't. I can't count the number of sysadmin/customers/ hosting providers that freak out when something like that appears in the log and call us and we have to explain that yes, it's not logical but... Do people want this also for 2.8? Note that it changes the log format, so may break third party tools that parse logs. I was planning on rolling my changes out to 2.8, 2.9 and the trunk. Unless anyone strenuously objects, I still intend to do that. I cleaned up a lot of the code and made a few other changes that generally improve logging. It's a shame Florent and I were genuinely working on this at the same time without the other knowing... Well, I told you on the list that I was already working on this. You didn't pay attention I guess. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On 2 Dec 2005, at 11:09, Chris Withers wrote: I was planning on rolling my changes out to 2.8, 2.9 and the trunk. Unless anyone strenuously objects, I still intend to do that. I cleaned up a lot of the code and made a few other changes that generally improve logging. I strenuously object to you overwriting without consultation code I just checked in and that was approved by at least 3 people. And I'm totally -1 on any logging at level INFO or above about retriable conflict errors. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
Florent Guillaume wrote: It doesn't really matter, zLOG has a compatibility layer that ends up doing the same thing. python's logging module has a cleaner, nicer syntax. Please no. Don't put anything at INFO. A conflict error is either something normal that should be at level BLATHER or below, or an ERROR that a sysadmin wants to see logged as such. Not so. If I'm getting 1,000 resolved conflict errors a day, that can be a big performance hit, and there are those of us who have hard performance targets to meet ;-) Turning on debug logging is, in itself, a performance hit, so I don't want to have to do that on a production service where I want to observe the number of conflict errors occurring over a long period of time, like, say, a month. INFO sucks for recurring stuff like that that in addition contain the word error which it isn't. Well, that's a problem with the exception naming, and I agree with you, but I don't know how hard that is to change. I can't count the number of sysadmin/customers/ hosting providers that freak out when something like that appears in the log and call us and we have to explain that yes, it's not logical but... Stupid sysadmins can't be helped. It's being logged at INFO, not ERROR or WARNING. I agree, the exception should be renamed to just Conflict, but that's a totally different discussion. Well, I told you on the list that I was already working on this. You didn't pay attention I guess. You made a vague comment on the 21st Nov. I made a definite commitment on the 24th Nov. On the 25th, you said you were working on it in response to my question. Now, by yesterday, 6 days later, nothing had happened, so I fixed this and did some other work with stupid error messages along the way. Then, suddenly, yesterday you commit. *sigh* Anyway, I'm going to check in the changes because they're materially the same but the code is cleaner. Whether resolved conflict errors are logged at INFO or DEBUG is a seperate discussion and one which I'd like to see a lot more comments on than have been seen so far. The +1s from people yesterday were about the general merging of the fix to 2.8, which I would also +1 to ;-) However, changing from INFO to DEBUG is a change in functionality which _I_ strenuously object to. People _need_ to be aware that they are seeing conflict errors, even if they are resolved. I, for one, really really want to be able to look in the event log and see if _any_ conflict errors are occurring, resolved or not, and keep track of the number of them so I can spot any performance hotspots before they become critical. FWIW, the stuff I log at INFO makes it clearer as to which conflicts are resolved or not, so your sysadmin types should be happier. What do people other than Florent, whose view I think we know, feel about this? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
Florent Guillaume wrote: Please no. Don't put anything at INFO. A conflict error is either something normal that should be at level BLATHER or below, or an ERROR that a sysadmin wants to see logged as such. Incidentally, your changes result in most users seeing two errors in their logs when they should just see one. I'm not aware of many serious users who don't copy the output of the error_log object to the event log, so with your changes, you'll end up with the error that ends up in the error_log, and your seperate LOG call's message. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On 2 Dec 2005, at 14:16, Chris Withers wrote: Please no. Don't put anything at INFO. A conflict error is either something normal that should be at level BLATHER or below, or an ERROR that a sysadmin wants to see logged as such. Not so. If I'm getting 1,000 resolved conflict errors a day, that can be a big performance hit, and there are those of us who have hard performance targets to meet ;-) Turning on debug logging is, in itself, a performance hit, so I don't want to have to do that on a production service where I want to observe the number of conflict errors occurring over a long period of time, like, say, a month. I agree with this argumentation. It is true that conflicts are a normal part of operation, as we all like to tell people who are scared/confused by them, but if you see so many that it bothers you seeing it at INFO level you know you have a problem that needs fixing. Same is true for the panicking sysadmins that call up the developers. If they call because of that they should have gotten better training before starting to admin Zope setups, or they shouldn't be doing it at all. jens ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1919 Blamelist: chrisw,ctheune BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
What test failed here? Chris [EMAIL PROTECTED] wrote: The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1919 Blamelist: chrisw,ctheune BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Logging of ConflictError
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: On 2 Dec 2005, at 11:09, Chris Withers wrote: I was planning on rolling my changes out to 2.8, 2.9 and the trunk. Unless anyone strenuously objects, I still intend to do that. I cleaned up a lot of the code and made a few other changes that generally improve logging. I strenuously object to you overwriting without consultation code I just checked in and that was approved by at least 3 people. And I'm totally -1 on any logging at level INFO or above about retriable conflict errors. Likewise -1. A successfully retried conflict should not clutter up the log. In another message, Chris wrote: Not so. If I'm getting 1,000 resolved conflict errors a day, that can be a big performance hit, and there are those of us who have hard performance targets to meet ;-) Turning on debug logging is, in itself, a performance hit, so I don't want to have to do that on a production service where I want to observe the number of conflict errors occurring over a long period of time, like, say, a month. You need to plan to set up and *additional* logging handler for this, which logs *only* conflict errors at *whatever* level, rather than requiring everybody else to live with output they don't need or want to see. I figured out how to do this once, long ago, to surface some obscure BLATHER-level notification; given your familiarity with the logging module, it should be a snap for you. ;) Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDkF3j+gerLs4ltQ4RAsLtAJ90STWiXGtO77wMZJ7c0Y7R8a22yQCeIW9/ 7Qe7tteducXydAGO54RpkJg= =u8L+ -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1921 Blamelist: chrisw BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Python2.4 Security Audit ETA???
Christian Theune wrote: Hi, Am Mittwoch, den 30.11.2005, 15:52 +0100 schrieb Philipp von Weitershausen: Andreas Jung wrote: Let's say it this way: it's safer than with Zope 2.8.3 but it is still not supported :-) From where I'm standing, with Zope 2.8.4 it's as safe as with Zope 2.9 (which actually *requires* Python 2.4...) So it is really just a label we put on the 2.8 and 2.9 branches, in terms of the relevant code base they're the same... Statements like that are *dangerous*. The label is all that it is about. It is against the possibility that although the likely relevant code base is the same, there might be some minor minor minor switch that makes everything burn. I really can't figure out what your saying. There are _several_ major linux distributions out there that already ignore this label and shipped Zope with Python 2.4. It's not helpful to argue them out of that if we don't care for the label ourselves. Python 2.4 is not supported for current production Zopes. This has been clearly stated for some time. We can't prevent people from ignoring this and creating Zope distributions based on an unsupported Python. People who release Zope for unsupported Python releases are doing their users a disservice. In this case, there was a reasonably serious security problem introduced by Python 2.4. What Andreas is saying is that Python 2.4 still isn't supported for Zope 2.8. This is different from a statement about a security audit. The security audit evaluated and addressed issues arising from a change from Python 2.3 to python 2.4. Zope 2.8.4 reflects this. We still choose not to support Python 2.4 for Zope 2.8 because there hasn't been any sort of test release cycle for Zope 2.8 with Python 2.4. Zope 2.9 will go through such a cycle which will give us at least some consequence. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
[EMAIL PROTECTED] wrote: The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1921 Blamelist: chrisw BUILD FAILED: failed test OK, I think I got it, I guess we'll see... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Python2.4 Security Audit ETA???
Hi, Am Freitag, den 02.12.2005, 10:03 -0500 schrieb Jim Fulton: Christian Theune wrote: Am Mittwoch, den 30.11.2005, 15:52 +0100 schrieb Philipp von Weitershausen: From where I'm standing, with Zope 2.8.4 it's as safe as with Zope 2.9 (which actually *requires* Python 2.4...) So it is really just a label we put on the 2.8 and 2.9 branches, in terms of the relevant code base they're the same... Statements like that are *dangerous*. The label is all that it is about. It is against the possibility that although the likely relevant code base is the same, there might be some minor minor minor switch that makes everything burn. I really can't figure out what your saying. Sorry. See my response a couple of lines downwards. What Andreas is saying is that Python 2.4 still isn't supported for Zope 2.8. This is different from a statement about a security audit. The security audit evaluated and addressed issues arising from a change from Python 2.3 to python 2.4. Zope 2.8.4 reflects this. We still choose not to support Python 2.4 for Zope 2.8 because there hasn't been any sort of test release cycle for Zope 2.8 with Python 2.4. Zope 2.9 will go through such a cycle which will give us at least some consequence. If I didn't miss anything, neither an audit has happend for Zope 2.8 with Python 2.4, nor did we make it a supported platform. IMHO it is dangerous to call it just a label that we apply. If the audit was performed, then I'll shut up immediately. I just think that it can happen more easily that someone picks up that's *just* a label and will ignore recommendations in the future. If that happens those ignoring the recommendations can of course not blame us, but it creates more trouble than necessary. Just my 0.02 EUR ... Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Logging of ConflictError
I initially gave Florent's proposal a +1 because frankly I'm kinda sick of answering people's questions about conflict errors (this deserves some treatment in docs actually). But I do agree that it is useful to be able to see conflict errors in non-blather logs when you *do* know what they mean; I was just going to patch Zope myself locally to be able to see them after Florent applied his for the masses patch. If other people like Chris feel strongly about displaying them, I'm not going to complain much. Sometimes it's useful for people who *don't* know what they mean to see them so that when their myisam tables have three copies of a row or their mailhost is sending two emails instead of one, that we can ask them to go look at their logs and search for a conflict error. The answer is always the same.. use a transactional doodad, but it's useful to be able to get there with them. IOW, either way is fine by me. On Dec 2, 2005, at 10:09 AM, Chris Withers wrote: Tres Seaver wrote: I strenuously object to you overwriting without consultation code I just checked in and that was approved by at least 3 people. And I'm totally -1 on any logging at level INFO or above about retriable conflict errors. Likewise -1. A successfully retried conflict should not clutter up the log. Huh? How is it cluttering up the log? At INFO level, I assert that if you see enough of these to judge them clutter, you really ought to have a look at where they're coming from and solve the performance problem they'll be causing... Not so. If I'm getting 1,000 resolved conflict errors a day, that can be a big performance hit, and there are those of us who have hard performance targets to meet ;-) Turning on debug logging is, in itself, a performance hit, so I don't want to have to do that on a production service where I want to observe the number of conflict errors occurring over a long period of time, like, say, a month. You need to plan to set up and *additional* logging handler for this, OK, first point, Florent's change was one that changed existing functionality that I, for one, was relying on. Should that really be happening on the 2.8 branch at the very least? which logs *only* conflict errors at *whatever* level, rather than requiring everybody else to live with output they don't need or want to see. I still assert that the belief it is information you shouldn't want to see is incorrect. I figured out how to do this once, long ago, to surface some obscure BLATHER-level notification; given your familiarity with the logging module, it should be a snap for you. ;) Yes, unfortunately it's this familiarity that means I can point out the problem. At some point in 2.8's development, someone made the bright idea of having the event log be the root python logger. While I liked this in theory, in practice it means you can't set up seperate logs in the way you describe, since everything ends up getting fired at the event log anyway :-( Then there's the issue that zope.conf doesn't support the configuration of additional loggers, when it really should ;-) I'm happy to try and find time to work on the latter issue, if whoever made the change that resulted in the former 'fesses up and explains why the change was made. In either case, I don't think it's fair to require this problem be solved in order for necessary conflict error logging to be resumed :-( Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
On Dec 2, 2005, at 9:49 AM, Chris Withers wrote: What test failed here? Go to ... [EMAIL PROTECTED] wrote: The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. This url: Buildbot URL: http://buildbot.zope.org/ Click on the 'log' link for the failed test. In this particular case you would have gone to http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/ builds/86/test/0 (I saw you think you fixed it, and I see that buildbot is now testing the changes, but you didn't say that you figured out the answer to your question) Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Python2.4 Security Audit ETA???
Christian Theune wrote: Hi, Am Freitag, den 02.12.2005, 10:03 -0500 schrieb Jim Fulton: Christian Theune wrote: Am Mittwoch, den 30.11.2005, 15:52 +0100 schrieb Philipp von Weitershausen: From where I'm standing, with Zope 2.8.4 it's as safe as with Zope 2.9 (which actually *requires* Python 2.4...) So it is really just a label we put on the 2.8 and 2.9 branches, in terms of the relevant code base they're the same... Statements like that are *dangerous*. The label is all that it is about. It is against the possibility that although the likely relevant code base is the same, there might be some minor minor minor switch that makes everything burn. I really can't figure out what your saying. Sorry. See my response a couple of lines downwards. What Andreas is saying is that Python 2.4 still isn't supported for Zope 2.8. This is different from a statement about a security audit. The security audit evaluated and addressed issues arising from a change from Python 2.3 to python 2.4. Zope 2.8.4 reflects this. We still choose not to support Python 2.4 for Zope 2.8 because there hasn't been any sort of test release cycle for Zope 2.8 with Python 2.4. Zope 2.9 will go through such a cycle which will give us at least some consequence. If I didn't miss anything, neither an audit has happend for Zope 2.8 with Python 2.4, nor did we make it a supported platform. You did miss something. As has been pointed out several times in this thread, the audit did happen for 2.8 and 2.8. And, as has also been said many times, Python 2.4 with Zope 2.8 is not supported. IMHO it is dangerous to call it just a label that we apply. I really don't know what it you are refering to. We did do the security audit. We still aren't supporting Python 2.4 for Zope 2.8. If the audit was performed, then I'll shut up immediately. Cool. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
Gary Poster wrote: This url: Buildbot URL: http://buildbot.zope.org/ Yup, got this now, so when you see buildbot failures, go here :-) cheers, Chris - who's finally starting ot understand what buildbot does! -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RFC: _verifyObjectPaste cleanup
Hi! Basically I'd like to remove the workaround introduced to fix http://www.zope.org/Collectors/Zope/78 : http://svn.zope.org/Zope/trunk/lib/python/OFS/CopySupport.py?view=diffr1=24022r2=24021 checkPermission now respects proxy roles, so this workaround is no longer needed. Replacing the workaround by a checkPermission call will make the 'permission' key in all_meta_types required, the 'action' key becomes optional. The old code did have a fallback for meta_types without 'permission' key. This is the comment for the fallback: # XXX: Ancient cruft, left here in true co-dependent fashion #to keep from breaking old products which don't put #permissions on their metadata registry entries. Is it save to make the 'permission' key required? Or do we need the fallback for 'ancient cruft'? There might be new products that don't set the 'permission' key because it wasn't enforced until now. I propose to - leave Zope 2.7 untouched - use checkPermission in Zope 2.8 and add the fallback with deprecation warning - make the 'permission' key required in Zope 2.9 and later Any comments? Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On Fri, Dec 02, 2005 at 02:09:56PM +0100, Florent Guillaume wrote: On 2 Dec 2005, at 11:09, Chris Withers wrote: I was planning on rolling my changes out to 2.8, 2.9 and the trunk. Unless anyone strenuously objects, I still intend to do that. I cleaned up a lot of the code and made a few other changes that generally improve logging. I strenuously object to you overwriting without consultation code I just checked in and that was approved by at least 3 people. I'm +1 on having failed retries show up at level ERROR. I'm neutral on having successful retries show up at level INFO, BLATHER, or in some other log handler entirely. Conflict errors are a pretty small part of my world and I don't really have a strong opinion on this part of the debate, and I don't have time to review either of your patches. -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Logging of ConflictError
On Fri, Dec 02, 2005 at 03:09:40PM +, Chris Withers wrote: | Then there's the issue that zope.conf doesn't support the configuration | of additional loggers, when it really should ;-) | | I'm happy to try and find time to work on the latter issue, if whoever | made the change that resulted in the former 'fesses up and explains why | the change was made. I was looking at the same issue yesterday, and it's really a trivial change. Need to add a 'multisection' to zopeschema.xml that allows multiple 'logger' type entries. Then you can just do something like: logger this.that.the_other level BLATHER propagate 0 # if you don't want it to end up in error.log logfile level BLATHER path $INSTANCE/log/theother.log /logfile /logger I haven't gotten around to make the proposal for change, but since you did, here's my 2 cents. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] toplevel products folder in zope svn ?
Anyone know if there is any plan to add a toplevel products folder in the zope svn repo like there currently is in zope's cvs repo? I know this has held up a few products from going from zope CVS to SVN. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: _verifyObjectPaste cleanup
yuppie wrote at 2005-12-2 16:50 +0100: ... checkPermission now respects proxy roles, so this workaround is no longer needed. But we should also have some way to check permissions without proxy roles: It sometimes is useful for something with a proxy role to check whether the user (without a proxy) could perform the operation as well. Thus, if checkPermission changed its behaviour, it probably should get an optional parameter to get the old behaviour back. Otherwise, I am happy with your cleanup. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
Florent Guillaume wrote at 2005-12-1 19:49 +0100: I've improved the logging of ConflictError in Zope 2.9 and trunk. http://svn.zope.org/?rev=40454view=rev Now you'll get two things: - logs at level BLATHER for each conflict, but it may be retried - log at level ERROR when the conflict can't be retried anymore and is returned to the browser as an error. Apparently, you stopped following our thread (you, Chris, me): In my view, a ConflictError observed by the user should be treated exactly like any other exception observed by the user: it should go through the error_log and standard_error_message. It might be logged (when the user decides that exceptions seen by the user should be logged). The approach to achieve this it to fix a bug in Zope's zpublisher_exception_hook, not to add an explicit log when the final retry fails (though the extra log entry will not hurt significantly). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeyError: 'URL' in HTTPRequest using zope2.7-py2.3.3
Brian Watson wrote at 2005-12-1 20:55 -0500: brian w. Traceback (most recent call last): File E:\NBCJEAP\Zope\lib\python\zExceptions\ExceptionFormatter.py, line 157, in formatLine result.extend(self.formatSupplement(supp, tb)) File E:\NBCJEAP\Zope\lib\python\zExceptions\ExceptionFormatter.py, line 105, in formatSupplement extra = self.formatExtraInfo(supplement) File E:\NBCJEAP\Zope\lib\python\zExceptions\ExceptionFormatter.py, line 231, in formatExtraInfo extra = getInfo(1) File E:\NBCJEAP\Zope\lib\python\Products\PageTemplates\TALES.py, line 277, i n getInfo ... File E:\NBCJEAP\Zope\lib\python\ZPublisher\HTTPRequest.py, line 1295, in __r epr__ return %s, URL=%s % (self.__class__.__name__, self['URL']) File E:\NBCJEAP\Zope\lib\python\ZPublisher\HTTPRequest.py, line 1214, in __g etitem__ raise KeyError, key KeyError: 'URL' The request in your PageTemplate context lacks an URL. URL is set in the HTTPRequests constructor (__init__). If an HTTPRequest instance lacks URL this means either: * the instance was created in a wrong way (contructor not called) * URL was deleted after construction. Unfortunately, the details you have provided does not allow to say more about this problem. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Folderish or SimpleItem object types for structural content
Martijn Jacobs wrote at 2005-12-1 01:06 +0100: ... If some conflict errors occure or for some reason the objects are not indexed (correctly) or not updated, some important information is not available for the user. I have experienced alot of problems with unindexed objects, or not reindexed objects due to 'random' conflict errors'. If random conflict errors lead to inconsistencies (object modified but not reindexed), then they are very badly handled: Any exception that bubbles up to ZPublisher causes the complete transaction to be aborted: the effect will be neither an object modification nor a reindexing. If the object is modified but not reindexed in the context of a ConflictError, then something must have caught the ConflictError -- a very bad thing... Unfortunately, unrestricted try: ... except: ... is not too uncommon. Zope some problems in this respect but meanwhile almost all places have been cleaned up. But usually, when an object is modified but not reindexed, it is the application (and not a ConflictError) that made the error -- it often forgets to call the reindex. By making a complete hierarchical structure using 'Object Managers', you can always assure that data is accessible, and if the ZCatalog is not up to date, only the search results will not represent the actual structure. A much more important reason for this structure is acquisition (which you will loose when you follow my proposal). 30.000 is not yet very impressing. That's good to know. It's hard to say offcourse, but what is in some way a 'limit' of the number of objects, for instance, if they all have to be indexed? Indexing objects uses ALOT of CPU time for example... In which amount of objects should you reconsider your design? (Speaking of a 'general' guideline) Usually, you index incrementally (one object at a time). The data structures involved when indexing a single object behave logarithmically in the total number of objects. Thus, I am not worried to have lots of objects indexed in the catalog. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
Florent Guillaume wrote at 2005-12-2 13:33 +0100: ... Please no. Don't put anything at INFO. A conflict error is either something normal that should be at level BLATHER or below, or an ERROR that a sysadmin wants to see logged as such. I strongly disagree with you: ConflictErrors are essential hints that your system might come into trouble (they can turn into real error). These hints are at least as important as e.g. 2005-12-02T07:17:59 INFO ZODB.Mount Opening database for mounting: '144160968_1010482273.050062' -- 2005-12-02T07:17:59 INFO ZODB.Mount Mounted database '144160968_1010482273.050062' at /temp_folder Looks like INFO is a better level than BLATHER... -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On 2 Dec 2005, at 20:40, Dieter Maurer wrote: Florent Guillaume wrote at 2005-12-1 19:49 +0100: I've improved the logging of ConflictError in Zope 2.9 and trunk. http://svn.zope.org/?rev=40454view=rev Now you'll get two things: - logs at level BLATHER for each conflict, but it may be retried - log at level ERROR when the conflict can't be retried anymore and is returned to the browser as an error. Apparently, you stopped following our thread (you, Chris, me): In my view, a ConflictError observed by the user should be treated exactly like any other exception observed by the user: it should go through the error_log and standard_error_message. That's what my patch did. It might be logged (when the user decides that exceptions seen by the user should be logged). I can agree with that. The approach to achieve this it to fix a bug in Zope's zpublisher_exception_hook, not to add an explicit log when the final retry fails (though the extra log entry will not hurt significantly). The patch I did included the fix you proposed in the patch in the mailing list archives based on the collector entry. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On 2 Dec 2005, at 20:50, Dieter Maurer wrote: Florent Guillaume wrote at 2005-12-2 13:33 +0100: ... Please no. Don't put anything at INFO. A conflict error is either something normal that should be at level BLATHER or below, or an ERROR that a sysadmin wants to see logged as such. I strongly disagree with you: ConflictErrors are essential hints that your system might come into trouble (they can turn into real error). These hints are at least as important as e.g. 2005-12-02T07:17:59 INFO ZODB.Mount Opening database for mounting: '144160968_1010482273.050062' -- 2005-12-02T07:17:59 INFO ZODB.Mount Mounted database '144160968_1010482273.050062' at /temp_folder Looks like INFO is a better level than BLATHER... If you look at the way their purpose is explained in zLOG, you'll see that level INFO is reserved for things like server startup and shutdown. Or, as shown above, initial mounting of databases. Anything recurring that can happen many times in the life of the server but does not pose any problems should *not* be visible at INFO. On the other hand, that's exactly what BLATHER is for folks! Use it! Note that it's another reason for not using the default python loggers who have a stupidly small number of levels. If you want to audit your server status to see if there are changes real errors will happen, INFO is *not* the level to use. Anyway, there's sufficient disagreement here, I'll send another mail to ask for people's votes. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Please vote about conflict errors logging
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) I'll wait until Wednesday morning to collect results. Thanks, Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please vote about conflict errors logging
1. Do you want these ConflictErrors retried logs to be at level: INFO 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? no traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: ERROR jens ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Please vote about conflict errors logging
Here's my own vote :) 1. Do you want these ConflictErrors retried logs to be at level: BLATHER 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? No, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: ERROR Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please vote about conflict errors logging
On Dec 2, 2005, at 5:00 PM, Florent Guillaume wrote: Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other INFO or BLATHER 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback Traceback if at BLATHER, no traceback if at INFO. 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other ERROR (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) I'll wait until Wednesday morning to collect results. Thanks, Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please vote about conflict errors logging
1. INFO 2. Yes, with traceback (necessary as these are heissenevents) 3. ERROR 4. don't care -- we can adapt Thanks Florent for taking the lead on this. I think it's a great help. On Fri, 2 Dec 2005, Florent Guillaume wrote: Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) I'll wait until Wednesday morning to collect results. Thanks, Florent -- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please vote about conflict errors logging
Florent Guillaume wrote: Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other BLATHER (I have never be able to get any meaningful information from them, except that zope tries several times) 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback Full traceback, since we're in BLATHER mode 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other ERROR /JM (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) I'll wait until Wednesday morning to collect results. Thanks, Florent ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Please vote about conflict errors logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other BLATHER 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback Yes, with traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other ERROR (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) Make it the same. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDkQ+++gerLs4ltQ4RAhDrAJ9pjTXb9F6bEoZGQ1xTA2lyI47knQCgiXWK 8blEg0KiwVIIKlt95gK9CPg= =JUyS -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
Paul Winkler wrote: I'm +1 on having failed retries show up at level ERROR. With Florent's changes you get 'em twice, with mine, you get 'em once ;-) I'm neutral on having successful retries show up at level INFO, BLATHER, or in some other log handler entirely. Conflict errors are a pretty small part of my world and I don't really have a strong opinion on this part of the debate, and I don't have time to review either of your patches. Well, if you ever run into performance problems, you might care about them... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Logging of ConflictError
Sidnei da Silva wrote: I was looking at the same issue yesterday, and it's really a trivial change. Need to add a 'multisection' to zopeschema.xml that allows multiple 'logger' type entries. Then you can just do something like: Yes, that bit is simple. But in 2.8.something and above, the eventlog is plugged in as a root logger, meaning you can't get anything logged that doesn't go to it. Who made this change and why? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please vote about conflict errors logging
Florent Guillaume wrote: 1. Do you want these ConflictErrors retried logs to be at level: - INFO 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - No, without traceback The actual traceback for any conflict error is pretty useless, since it comes from one of very few places inside zodb 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR ...ie: handled in the same way as any other user-visible error: standard_error_message and error_log. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please vote about conflict errors logging
Jean-Marc Orliaguet wrote: BLATHER (I have never be able to get any meaningful information from them, except that zope tries several times) That's because they excluded any useful information before. The implementation I've put in tells you, at info level, what error actually occurred, what object it occurred on, how many conflicts occurred since server start and how many of those were resolved. It's compact and informative. I'd suggest anyone who's voting for blather should actually check out the trunk and try the functional test I put in to see the new code in action... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Logging of ConflictError
On Dec 2, 2005, at 3:51 PM, Chris Withers wrote: Sidnei da Silva wrote: I was looking at the same issue yesterday, and it's really a trivial change. Need to add a 'multisection' to zopeschema.xml that allows multiple 'logger' type entries. Then you can just do something like: Yes, that bit is simple. But in 2.8.something and above, the eventlog is plugged in as a root logger, meaning you can't get anything logged that doesn't go to it. Who made this change and why? Yes you can. Just set 'propagate' to a non-true value. -- Sidnei da Silva Enfold Systems, LLC http://enfoldsystems.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
