Re: [Zope] filter messages at startup
i mean i would like to filter warning/error messages that appears in console when starting zope server or debugger in order to ignore those i'm not interested with for the moment for instance : [root@biow3 tests]# /zope/test/bin/zopectl debug Starting debugger (the name "app" is bound to the top-level Zope object) 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' etc 2006/6/13, Andreas Jung <lists@zopyx.com>:
--On 13. Juni 2006 11:28:51 +0200 thomas desvenain <thomas.desvenain@gmail.com> wrote:
hello,
is it possible to filter messages at zope startup/debug, as we can do with logs ?
What does that mean? What is the usecase?
-aj
-- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
thomas desvenain wrote:
i mean i would like to filter warning/error messages that appears in console when starting zope server or debugger in order to ignore those i'm not interested with for the moment
for instance :
[root@biow3 tests]# /zope/test/bin/zopectl debug Starting debugger (the name "app" is bound to the top-level Zope object) 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' etc
Not out of the box. But these warnings are symptoms of a problem: you should really upgrade CMF though, which fixes those. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote:
thomas desvenain wrote:
i mean i would like to filter warning/error messages that appears in console when starting zope server or debugger in order to ignore those i'm not interested with for the moment
for instance :
[root@biow3 tests]# /zope/test/bin/zopectl debug Starting debugger (the name "app" is bound to the top-level Zope object) 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' etc
Not out of the box.
But these warnings are symptoms of a problem: you should really upgrade CMF though, which fixes those.
Florent
I get these messages on fields too, under Five for zope3 classes: 2006-06-13 17:49:52 WARNING Init Class cpsskins.standard.ds.html.HTML has a security declaration for nonexistent method 'html' with: class IHTML(Interface): """Plain HTML """ html = TextLine( title=_(u"HTML"), description=_(u"Plain HTML content."), required=False, ) class HTML(object): """Plain HTML content """ implements(IHTML) it seems that zope2 believes that these are methods. /JM
On Jun 13, 2006, at 11:05 AM, Florent Guillaume wrote:
thomas desvenain wrote:
i mean i would like to filter warning/error messages that appears in console when starting zope server or debugger in order to ignore those i'm not interested with for the moment for instance : [root@biow3 tests]# /zope/test/bin/zopectl debug Starting debugger (the name "app" is bound to the top-level Zope object) 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' etc
Not out of the box.
Actually, there is a way, but it's a bit heavy-handed and imprecise. In zope.conf, do (untested): <warnfilter> action ignore message .*has a security declaration for.* </warnfilter> Here's the ZConfig schema description of the "warnfilter" element: <multisection type="warnfilter" attribute="warnfilters" name="*" dataype="zLOG.warn_filter_handler"> <!-- from zLOG --> <description> A multisection which allows a user to set up a Python "warning" filter. The following keys are valid within a warnfilter section: action: one of the following strings: "error" turn matching warnings into exceptions "ignore" never print matching warnings "always" always print matching warnings "default" print the first occurrence of matching warnings for each location where the warning is issued "module" print the first occurrence of matching warnings for each module where the warning is issued "once" print only the first occurrence of matching warnings, regardless of location message: a string containing a regular expression that the warning message must match (the match is compiled to always be case-insensitive) category: a Python dotted-path classname (must be a subclass of Warning) of which the warning category must be a subclass in order to match module: a string containing a regular expression that the module name must match (the match is compiled to be case-sensitive) lineno: an integer that the line number where the warning occurred must match, or 0 to match all line numbers </description> </multisection> - C
Not out of the box.
Egads, I think you're right. These aren't actual warnings, are they? They're log calls. That should be changed. - C
Actually, there is a way, but it's a bit heavy-handed and imprecise. In zope.conf, do (untested):
<warnfilter> action ignore message .*has a security declaration for.* </warnfilter>
Here's the ZConfig schema description of the "warnfilter" element:
<multisection type="warnfilter" attribute="warnfilters" name="*" dataype="zLOG.warn_filter_handler"> <!-- from zLOG --> <description> A multisection which allows a user to set up a Python "warning" filter. The following keys are valid within a warnfilter section:
action: one of the following strings:
"error" turn matching warnings into exceptions "ignore" never print matching warnings "always" always print matching warnings "default" print the first occurrence of matching warnings for each location where the warning is issued "module" print the first occurrence of matching warnings for each module where the warning is issued "once" print only the first occurrence of matching warnings, regardless of location
message: a string containing a regular expression that the warning message must match (the match is compiled to always be case-insensitive)
category: a Python dotted-path classname (must be a subclass of Warning) of which the warning category must be a subclass in order to match
module: a string containing a regular expression that the module name must match (the match is compiled to be case-sensitive)
lineno: an integer that the line number where the warning occurred must match, or 0 to match all line numbers </description> </multisection>
- C
Indeed they are logging.getLogger("Init") calls (from App/ class_init.py). Why change that? They're perfectly fine in the event log. Florent On 13 Jun 2006, at 23:08, Chris McDonough wrote:
Not out of the box.
Egads, I think you're right. These aren't actual warnings, are they? They're log calls. That should be changed.
- C
[root@biow3 tests]# /zope/test/bin/zopectl debug Starting debugger (the name "app" is bound to the top-level Zope object) 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget'
-- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
I suppose a log call is fine. I *really* like these messages, because they catch a lot of my own boneheaded security declaration errors. But for ones that aren't actually "real" problems (like the ones shown by the OP), it would be nice to be able to filter them away at startup, especially when starting in the foreground or running "zopectl debug" or "zopectl test". Making these into actual warnings.warn calls would let us do that with a warnfilter, but any other solution would be fine as well. - C On Jun 13, 2006, at 5:18 PM, Florent Guillaume wrote:
Indeed they are logging.getLogger("Init") calls (from App/ class_init.py). Why change that? They're perfectly fine in the event log.
Florent
On 13 Jun 2006, at 23:08, Chris McDonough wrote:
Not out of the box.
Egads, I think you're right. These aren't actual warnings, are they? They're log calls. That should be changed.
- C
[root@biow3 tests]# /zope/test/bin/zopectl debug Starting debugger (the name "app" is bound to the top-level Zope object) 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget'
-- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
2006/6/13, Chris McDonough <chrism@plope.com>:
I suppose a log call is fine.
I *really* like these messages, because they catch a lot of my own boneheaded security declaration errors. But for ones that aren't actually "real" problems (like the ones shown by the OP), it would be nice to be able to filter them away at startup, especially when starting in the foreground or running "zopectl debug" or "zopectl test". Making these into actual warnings.warn calls would let us do that with a warnfilter, but any other solution would be fine as well.
In my way those messages can be usefull for everybody... but not at every time it would be nice to get a tool (using regexp) to adapt them to our present needs (installing a product, developping a product on a test instance for example)
- C
On Jun 13, 2006, at 5:18 PM, Florent Guillaume wrote:
Indeed they are logging.getLogger("Init") calls (from App/ class_init.py). Why change that? They're perfectly fine in the event log.
Florent
On 13 Jun 2006, at 23:08, Chris McDonough wrote:
Not out of the box.
Egads, I think you're right. These aren't actual warnings, are they? They're log calls. That should be changed.
- C
[root@biow3 tests]# /zope/test/bin/zopectl debug Starting debugger (the name "app" is bound to the top-level Zope object) 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget' 2006-06-13 13:48:34 WARNING Init Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPget'
-- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
--On 14. Juni 2006 10:25:57 +0200 thomas desvenain <thomas.desvenain@gmail.com> wrote:
2006/6/13, Chris McDonough <chrism@plope.com>:
I suppose a log call is fine.
I *really* like these messages, because they catch a lot of my own boneheaded security declaration errors. But for ones that aren't actually "real" problems (like the ones shown by the OP), it would be nice to be able to filter them away at startup, especially when starting in the foreground or running "zopectl debug" or "zopectl test". Making these into actual warnings.warn calls would let us do that with a warnfilter, but any other solution would be fine as well.
In my way those messages can be usefull for everybody... but not at every time it would be nice to get a tool (using regexp) to adapt them to our present needs (installing a product, developping a product on a test instance for example)
From the practical point of view: just close your eyes. When you run a server in production you will see those messages only in the logs. If you are a developer you should be aware of the content of the messages and fix your own code or upgrade the related products.
-aj
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 14, 2006, at 4:36 AM, Andreas Jung wrote:
--On 14. Juni 2006 10:25:57 +0200 thomas desvenain <thomas.desvenain@gmail.com> wrote:
2006/6/13, Chris McDonough <chrism@plope.com>:
I suppose a log call is fine.
I *really* like these messages, because they catch a lot of my own boneheaded security declaration errors. But for ones that aren't actually "real" problems (like the ones shown by the OP), it would be nice to be able to filter them away at startup, especially when starting in the foreground or running "zopectl debug" or "zopectl test". Making these into actual warnings.warn calls would let us do that with a warnfilter, but any other solution would be fine as well.
In my way those messages can be usefull for everybody... but not at every time it would be nice to get a tool (using regexp) to adapt them to our present needs (installing a product, developping a product on a test instance for example)
From the practical point of view: just close your eyes. When you run a server in production you will see those messages only in the logs. If you are a developer you should be aware of the content of the messages and fix your own code or upgrade the related products.
It's just not possible to upgrade components of every configuration. Sometimes you just need to live with some specific configuration for a while. It's not really a bad thing to have a known-working configuration, even if it's a little old. If we turned these log calls into warnings.warn calls, they could be filtered out by warnfilter configuration, no big deal, we could solve the "cant upgrade right now b ut don't want to see warnings" problem, nobody would need to write any code to filter out specific log messages or do anything else. I think that's practical too. This is what the warnings module is for. In particular, these specific errors indicate a totally harmless condition and the errors' existence in the log isn't helpful to consumers who for whatever reason can't upgrade. Developers will continue to see warnings.warn messages because they always run things in the foreground and warnings.warn messages are sent to stderr, so it's not like they'd miss any deprecation messages if we changed it. If developers were really interested in being anal about things, a warnfilter configuration can turn warning messages into errors for their specific sandbox. If they really, really wanted the messages to be written to a logfile, they can override warnings.showwarning in their site configuration. I doubt anybody will care that much, though. Given the above, if there's not total opposition to this, I'd volunteer to make these log calls into warnings during bugday tomorrow on the 2.8, 2.9, and 2.10 branches. It might be a good idea to turn all deprecation warnings in the core like this into warning messages, especially given that the core itself generates warnings now due to its own use of features that have been marked as deprecated. - - C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFEj9mE8sgUgRRnf6URAtE6AJ9U4qiIL+azduJpVb7vizGmfBn5rQCaAoao lH8rgzCU5/e1IpwTBPcwZTQ= =uQ3M -----END PGP SIGNATURE-----
--On 14. Juni 2006 05:40:15 -0400 Chris McDonough <chrism@plope.com> wrote:
Given the above, if there's not total opposition to this, I'd volunteer to make these log calls into warnings during bugday tomorrow on the 2.8, 2.9, and 2.10 branches. It might be a good idea to turn all deprecation warnings in the core like this into warning messages, especially given that the core itself generates warnings now due to its own use of features that have been marked as deprecated.
If you have the time, go ahead. But I think we should focus tomorrow on more important outstanding issues than such cosmetic annoyances. Andreas
Chris McDonough wrote:
It's just not possible to upgrade components of every configuration. Sometimes you just need to live with some specific configuration for a while. It's not really a bad thing to have a known-working configuration, even if it's a little old.
+sys.maxint
If we turned these log calls into warnings.warn calls, they could be filtered out by warnfilter configuration, no big deal, we could solve the "cant upgrade right now b ut don't want to see warnings" problem, nobody would need to write any code to filter out specific log messages or do anything else. I think that's practical too. This is what the warnings module is for.
+1
In particular, these specific errors indicate a totally harmless condition
I'm not sure missing or incorrect security declarations could be described as "totally harmless"...
2.9, and 2.10 branches. It might be a good idea to turn all deprecation warnings in the core like this into warning messages,
-1
especially given that the core itself generates warnings now due to its own use of features that have been marked as deprecated.
...which is pretty criminal imnsho :-/ Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (6)
-
Andreas Jung -
Chris McDonough -
Chris Withers -
Florent Guillaume -
Jean-Marc Orliaguet -
thomas desvenain