============ zLOG is dead ============ The zLOG package used for logging throughout ZODB, ZEO, and Zope 2 has been declared obsolete. All logging for Zope products will use the logging package from Python's standard library. The zLOG package still exists in Zope 2 and the separate package for ZODB, but it is now an API shim (or "façade") over the logging package. It is expected to wither away to nothing at some point. Why should you care? -------------------- This means that the environment variables EVENT_LOG_FILE, EVENT_LOG_SEVERITY, STUPID_LOG_FILE, STUPID_LOG_SEVERITY, and ZSYSLOG are no longer honored for Zope 2.8, ZODB, or ZEO. Zope 2 reads logging configuring from the zope.conf configuration file, and the test.py script for developers reads a log.ini file using the obnoxious configuration syntax provided by the logging package itself. If you use the ZODB distribution but not the rest of Zope, you probably want to start changing any of your code that uses zLOG to use the logging package. ZODB and ZEO will be changed to use the logging package directly as well to avoid dependence on the API shim. How can you help? ----------------- If you have some time to contribute to Zope development, the removal of zLOG calls from the ZODB and ZEO packages would be a welcome contribution. I've converted Signals/Signals.py and Zope/Startup/__init__.py, and some modules of ZODB and ZEO already use the logging package directly; these can serve as examples. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
+1 What is the recommend way to migrate existing code? I assume using: import logging logger = logging.getLogger(loggername). When I look through the Zope HEAD code then you are using e.g. 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we have to agree on some common usage of the logger names? E.g. for logging calls in the reST package....better using 'Zope' or 'reST'? -aj --On Dienstag, 13. April 2004 15:53 Uhr -0400 Fred Drake <fred@zope.com> wrote:
============ zLOG is dead ============
The zLOG package used for logging throughout ZODB, ZEO, and Zope 2 has been declared obsolete. All logging for Zope products will use the logging package from Python's standard library.
The zLOG package still exists in Zope 2 and the separate package for ZODB, but it is now an API shim (or "façade") over the logging package. It is expected to wither away to nothing at some point.
Why should you care? --------------------
This means that the environment variables EVENT_LOG_FILE, EVENT_LOG_SEVERITY, STUPID_LOG_FILE, STUPID_LOG_SEVERITY, and ZSYSLOG are no longer honored for Zope 2.8, ZODB, or ZEO. Zope 2 reads logging configuring from the zope.conf configuration file, and the test.py script for developers reads a log.ini file using the obnoxious configuration syntax provided by the logging package itself.
If you use the ZODB distribution but not the rest of Zope, you probably want to start changing any of your code that uses zLOG to use the logging package. ZODB and ZEO will be changed to use the logging package directly as well to avoid dependence on the API shim.
How can you help? -----------------
If you have some time to contribute to Zope development, the removal of zLOG calls from the ZODB and ZEO packages would be a welcome contribution. I've converted Signals/Signals.py and Zope/Startup/__init__.py, and some modules of ZODB and ZEO already use the logging package directly; these can serve as examples.
-Fred
On Wednesday 14 April 2004 01:49 am, Andreas Jung wrote:
What is the recommend way to migrate existing code?
I assume using:
import logging logger = logging.getLogger(loggername).
That works, and certainly matches what I've been doing, and what we see in the Zope 3 codebase as well.
When I look through the Zope HEAD code then you are using e.g. 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we have to agree on some common usage of the logger names? E.g. for logging calls in the reST package....better using 'Zope' or 'reST'?
I don't think there is a general convention at this time; where I've switched things over (only a few places), I've used what was being passed to zLOG.LOG as the subsystem parameter. Where there's no precedent... I don't know. A guiding convention would be nice; I could see using the package name if there's nothing else that sticks out as obvious. That doesn't match a lot of the existing usage, though. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
From: "Andreas Jung" <andreas@andreas-jung.com>
When I look through the Zope HEAD code then you are using e.g. 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we have to agree on some common usage of the logger names? E.g. for logging calls in the reST package....better using 'Zope' or 'reST'?
'reST' I guess is the onbious one. I would like to see something like this: For Zope core core: Zope.subsystem. i.e. 'Zope.Accesscontrol', 'Zope.OFS'. For the default lib/python/Product stuff: Either Zope.Product or just Product, ie 'MailHost' or 'Zope.MailHost'. Which I don't care, makes no matter for me, but consistency would be good. For other Products: Just the product name. In the case of CMF and CPS and other things, you could possibly decide to use 'CMF.Core' and 'CMF.Default' instead of 'CMFCore' and 'CMFDefault' by that also seems kinda silly. Right? //Lennart
--On Mittwoch, 14. April 2004 10:57 Uhr +0200 Lennart Regebro <regebro@nuxeo.com> wrote:
From: "Andreas Jung" <andreas@andreas-jung.com>
When I look through the Zope HEAD code then you are using e.g. 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we have to agree on some common usage of the logger names? E.g. for logging calls in the reST package....better using 'Zope' or 'reST'?
'reST' I guess is the onbious one. I would like to see something like this:
For Zope core core: Zope.subsystem. i.e. 'Zope.Accesscontrol', 'Zope.OFS'.
+1
For the default lib/python/Product stuff: Either Zope.Product or just Product, ie 'MailHost' or 'Zope.MailHost'. Which I don't care, makes no matter for me, but consistency would be good.
For consitency: Zope.Products.XXXX For lazy writers: Zope. XXXXX I prefer the second solution...everyone should know what are products and what are packages. In fact the name does not matter because you can see in the traceback where the error occurs. You don't get this information from the name directly.
For other Products: Just the product name. In the case of CMF and CPS and other things, you could possibly decide to use 'CMF.Core' and 'CMF.Default' instead of 'CMFCore' and 'CMFDefault' by that also seems kinda silly.
Keep the product name as it is...means Products/XXXX should use Zope.XXXX as logger name. No need to introduce a new mapping. Keep it simple. -aj
--On Mittwoch, 14. April 2004 16:45 Uhr +0200 Andreas Jung <andreas@andreas-jung.com> wrote:
--On Mittwoch, 14. April 2004 10:57 Uhr +0200 Lennart Regebro <regebro@nuxeo.com> wrote:
From: "Andreas Jung" <andreas@andreas-jung.com>
When I look through the Zope HEAD code then you are using e.g. 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we have to agree on some common usage of the logger names? E.g. for logging calls in the reST package....better using 'Zope' or 'reST'?
'reST' I guess is the onbious one. I would like to see something like this:
For Zope core core: Zope.subsystem. i.e. 'Zope.Accesscontrol', 'Zope.OFS'.
+1
For the default lib/python/Product stuff: Either Zope.Product or just Product, ie 'MailHost' or 'Zope.MailHost'. Which I don't care, makes no matter for me, but consistency would be good.
For consitency: Zope.Products.XXXX For lazy writers: Zope. XXXXX
I prefer the second solution...everyone should know what are products and what are packages. In fact the name does not matter because you can see in the traceback where the error occurs. You don't get this information from the name directly.
Of course this applies only if you have an error :-) Anyway....names should be kept as short as possible. -aj
From: "Andreas Jung" <andreas@andreas-jung.com>
Keep the product name as it is...means Products/XXXX should use Zope.XXXX as logger name. No need to introduce a new mapping. Keep it simple.
Yeah, but is it reasonable to think that people who write new products will do this? A rule that most people will break is a bad rule... That people working on Zope itself can be well versed enough to use Zope.XXXX for things in teh Zope repository seems reasonable. But will people working on Plone really use "Zope.CMFQuickInstaller"? Rather they will probably say just "CMFQuickInstaller", "CMF.QuickInstaller" och "Plone.QuickInstaller" or something. As with all management, people will do what seems natural to them, unless it doesn't work. There is no incentive to stick a "Zope." at the front, so I don't think people will. Besides, there is a benefit in not doing it, because then you can see what is a part of Zope and what is add-ons.
On Wednesday 14 April 2004 11:44 am, Lennart Regebro wrote:
Yeah, but is it reasonable to think that people who write new products will do this? A rule that most people will break is a bad rule... That people working on Zope itself can be well versed enough to use Zope.XXXX for things in teh Zope repository seems reasonable. But will people working on Plone really use "Zope.CMFQuickInstaller"? Rather they will probably say just "CMFQuickInstaller", "CMF.QuickInstaller" och "Plone.QuickInstaller" or something.
I would only expect any sort of leading "Zope." to apply to the software that ships as part of Zope 2. Other products and tools, like the CMF and Plone, should use a different prefix ("CMF." and "Plone." come to mind as reasonable candidates). -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Lennart Regebro wrote:
Yeah, but is it reasonable to think that people who write new products will do this? A rule that most people will break is a bad rule... That people working on Zope itself can be well versed enough to use Zope.XXXX for things in teh Zope repository seems reasonable. But will people working on Plone really use "Zope.CMFQuickInstaller"? Rather they will probably say just "CMFQuickInstaller", "CMF.QuickInstaller" och "Plone.QuickInstaller" or something.
This discussion smells like that string should be computed from introspection. Why can't it be computed from introspecting whatever code called the log method? (btw, is there an intro to Python's logger stuff? looks like I need to get up to speed on this...) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
From: "Chris Withers" <chris@simplistix.co.uk>
This discussion smells like that string should be computed from introspection.
Why can't it be computed from introspecting whatever code called the log method?
Well, first of all, how? __name__ should always be available, but that is the name of the file that you are in. That's not what you want to log. And most seem to prefer using Zope.MailHost instead of Products.MailHost to notify that it's a part of the standard Zope distro, which won't be possible. And then again you might want to override it for many different reasons. __name__ could be the default, though, I guess.
On Tue, 2004-04-20 at 10:01, Chris Withers wrote:
This discussion smells like that string should be computed from introspection.
Why can't it be computed from introspecting whatever code called the log method?
You probably could do it via sys._getframe(). I'm not sure you should though. ;)
(btw, is there an intro to Python's logger stuff? looks like I need to get up to speed on this...)
AFAIK, the online logging package docs are about it. That's not the easiest way to learn how to use the package unfortunately. -Barry
Barry Warsaw wrote:
AFAIK, the online logging package docs are about it. That's not the easiest way to learn how to use the package unfortunately.
*sigh* What is the easiest way then? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Wednesday 14 April 2004 10:45 am, Andreas Jung wrote:
For consitency: Zope.Products.XXXX For lazy writers: Zope. XXXXX
I prefer the second solution...everyone should know what are products and what are packages. In fact the name does not matter because you can see in the traceback where the error occurs. You don't get this information from the name directly.
I disagree. Not everyone that looks at the logs will be a site developer or Zope product or core developer. Keeping things explicit is reasonable.
Keep the product name as it is...means Products/XXXX should use Zope.XXXX as logger name. No need to introduce a new mapping. Keep it simple.
Keeping it simple is good, but I'd still like to see every logging subsystem in code that ships with the Zope 2 core start with "Zope." This is a potential backwards compatibility issue, though, since log-trawling tools are already using the names currently generated, as inconsistent as they are. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Wed, 2004-04-14 at 18:53, Fred Drake wrote:
Keeping it simple is good, but I'd still like to see every logging subsystem in code that ships with the Zope 2 core start with "Zope." This is a potential backwards compatibility issue, though, since log-trawling tools are already using the names currently generated, as inconsistent as they are.
There probably are no log-trawling tools. The output generated by zLOG is basically unparseable. - C
[Chris McDonough]
There probably are no log-trawling tools. The output generated by zLOG is basically unparseable.
Alas, that hasn't stopped people from writing trawlers to analyze ZEO server and client logs. That one's going to be my headache "to fix"(*), and has some urgency since ZODB/ZEO's use of zLOG is the only reason Zope3 still needs the zLOG package. people-who-like-regexps-don't-understand-"perverse"-ly y'rs - tim (*) Unless someone decides to do it before I get to it. False hope is a way of life <wink>.
Fred Drake wrote:
============ zLOG is dead ============
The zLOG package used for logging throughout ZODB, ZEO, and Zope 2 has been declared obsolete. All logging for Zope products will use the logging package from Python's standard library.
The zLOG package still exists in Zope 2 and the separate package for ZODB, but it is now an API shim (or "façade") over the logging package. It is expected to wither away to nothing at some point.
I have several questions regarding to the changes: * Do I need to take care that the messages are logged into the event log and on the console or can I safly use the logging package like:: from logging import getLogger LOG = getLogger('MyLogger') LOG.debug('foo') zLOG has logged the messages to the console when zope was started with runzope and the entries were logged to the event.log, too. * Does Zope 2.7.0 has the new logging facility? * If no: Will Zope 2.7.1 have the new logging facility or do I need to wait for Zope 2.8? ... I'm chatting with Andreas Jung right now. He is telling me that the logs don't get printed to the console and that the log level is missing in the event.log Christian
On Tuesday 20 April 2004 01:15 pm, Christian Heimes wrote:
Fred Drake wrote: * Do I need to take care that the messages are logged into the event log and on the console or can I safly use the logging package like:: ... zLOG has logged the messages to the console when zope was started with runzope and the entries were logged to the event.log, too.
I've responded to the note from Andreas; we need to decide just how this should be handled, but it should not require changes to code that uses logging.
* Does Zope 2.7.0 has the new logging facility?
Zope 2.7.x uses the logging package as a back-end to zLOG, but it uses it in a different way. For it to make sense to change this for 2.7.1 would mean backporting most or all of the relevant changes from the trunk. I've no plans to do so myself at this time. So for code that needs to be compatible with Zope 2.7.x, it's wise to stick with zLOG.
* If no: Will Zope 2.7.1 have the new logging facility or do I need to wait for Zope 2.8?
I think waiting until you can drop support for Zope 2.7.x is the right thing to do. I imaging the zLOG API shim will remain in Zope 2.x for a long time.
I'm chatting with Andreas Jung right now. He is telling me that the logs don't get printed to the console and that the log level is missing in the event.log
This was unintentional; you should have better results after an update from CVS. Thanks for bringing this up. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
participants (8)
-
Andreas Jung -
Barry Warsaw -
Chris McDonough -
Chris Withers -
Christian Heimes -
Fred Drake -
Lennart Regebro -
Tim Peters