Re: [Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
yuppie wrote: Or would be 'GenericSetup.content' enough? Yes, that looks nicer to me :-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
yuppie wrote: Have a look at MailingLogger's SummarisingLogger for ideas. Give it a go and let me know where the code is if you want me to take a look, I've got to know and love python's logging module quite well ;-) I had a quick look at MailingLogger, but it seems to do something different. Well yes, but it's the same technique ;-) We need 'per request' reports to give instant feedback in the setup tool. ...so instantiate the logger at the start of the request, and remove it at the end... The logging module is not aware of requests, so I can't see an easy way to make sure the log handler collects only messages for a specific request. Your code runs in some kind of loop, right? Put a try: finally: around that loop, add your logger before the try and remove it in the finally :-) That said, I'm not sure the logging module has a nice api for removing loggers, but I could be wrong... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
Hi Tres! Tres Seaver wrote: If there are no objections I'd like to make those changes either on your branch or after you merged your changes into the trunk. Go ahead and merge it to the branch -- I'll need to look at how the generated report changes to reflect the level. Done. The logger names are still a mess. Currently we have names on 3 levels: - product: 'GenericSetup' - setup step/handler ID: e.g. 'rolemap', 'toolset' - adapter/'component': e.g. 'SFWA', 'CSAFA' (BTW: what means 'SGAIFA'?) Should we combine all 3 levels in the dotted logger name? e.g. 'GenericSetup.content.CSAFA' Or would be 'GenericSetup.content' enough? Currently it is 'GenericSetup.CSAFA'. Maybe you've got an idea how to resolve this. Don't know what kind of 'component' name the reports need. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yuppie wrote:
> Hi Tres!
>
>
> Tres Seaver wrote:
>
>>> Hmm, it seems like that landed in the project-local repository from
>>> which GenericSetup originally sprang, but *after* GenericSetup landed in
>>> CMF's repository. I'm attaching the patch:
>>>
>>> - It uses the '_notes' field both to create an OFS.Image.File log of
>>> import runs, as well as to display at the bottom of the "Import"
>>> tab.
>>>
>>> - It echoes logged messages to zLOG.
>>>
>>> - It expands ISetupContext's API with methods 'note', 'listNotes',
>>> and 'clearNotes'. Stock implementations of ths API are in a new
>>> 'SetupContextBase' class.
>>>
>>> Note that the patch doesn't apply cleanly to the GenericSetup trunk;
>>> I'll have to work out why if we chose to land it.
>>
>>
>> OK, I've landed it (it was easier than I expected) on a new branch:
>>
>> http://svn.zope.org/CMF/branches/tseaver-resync_GenericSetup
>
>
> I tried hard to make the I/O adapters reusable outside GenericSetup. To
> become more independent from ISetupContext I propose to move the logging
> API into a separate interface and class. ISetupContext would just have a
> getLogger() method.
>
> I'm also missing different logging levels. The python logging module has
> a nice generic API for that.
>
> So I propose to use the same interface for the GenericSetup specific
> logger, making it replaceable by a python logger if the I/O handlers are
> used in a different context.
>
>
> For example this code in content.py::
>
> import_context.note('SGAIFA',
> 'no .ini file for %s/%s' % (subdir, cid))
> would be replaced by this code::
>
> logger = import_context.getLogger('SGAIFA')
> logger.info('no .ini file for %s/%s' % (subdir, cid))
>
> If there are no objections I'd like to make those changes either on your
> branch or after you merged your changes into the trunk.
Go ahead and merge it to the branch -- I'll need to look at how the
generated report changes to reflect the level.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDfIhy+gerLs4ltQ4RAvdGAJ9b+jFJeqmbQlwbBvksd1m1YpHgoQCgjeyr
E81zqXx8qvWWNTgUHVyTwM8=
=1+Tm
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
Hi Tres!
Tres Seaver wrote:
Hmm, it seems like that landed in the project-local repository from
which GenericSetup originally sprang, but *after* GenericSetup landed in
CMF's repository. I'm attaching the patch:
- It uses the '_notes' field both to create an OFS.Image.File log of
import runs, as well as to display at the bottom of the "Import"
tab.
- It echoes logged messages to zLOG.
- It expands ISetupContext's API with methods 'note', 'listNotes',
and 'clearNotes'. Stock implementations of ths API are in a new
'SetupContextBase' class.
Note that the patch doesn't apply cleanly to the GenericSetup trunk;
I'll have to work out why if we chose to land it.
OK, I've landed it (it was easier than I expected) on a new branch:
http://svn.zope.org/CMF/branches/tseaver-resync_GenericSetup
I tried hard to make the I/O adapters reusable outside GenericSetup. To
become more independent from ISetupContext I propose to move the logging
API into a separate interface and class. ISetupContext would just have a
getLogger() method.
I'm also missing different logging levels. The python logging module has
a nice generic API for that.
So I propose to use the same interface for the GenericSetup specific
logger, making it replaceable by a python logger if the I/O handlers are
used in a different context.
For example this code in content.py::
import_context.note('SGAIFA',
'no .ini file for %s/%s' % (subdir, cid))
would be replaced by this code::
logger = import_context.getLogger('SGAIFA')
logger.info('no .ini file for %s/%s' % (subdir, cid))
If there are no objections I'd like to make those changes either on your
branch or after you merged your changes into the trunk.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
Tres Seaver wrote: Hmm, it seems like that landed in the project-local repository from which GenericSetup originally sprang, but *after* GenericSetup landed in CMF's repository. I'm attaching the patch: - It uses the '_notes' field both to create an OFS.Image.File log of import runs, as well as to display at the bottom of the "Import" tab. - It echoes logged messages to zLOG. - It expands ISetupContext's API with methods 'note', 'listNotes', and 'clearNotes'. Stock implementations of ths API are in a new 'SetupContextBase' class. Note that the patch doesn't apply cleanly to the GenericSetup trunk; I'll have to work out why if we chose to land it. OK, I've landed it (it was easier than I expected) on a new branch: http://svn.zope.org/CMF/branches/tseaver-resync_GenericSetup Great! Looks like almost everything I was missing regarding logging is already implemented. I'll have a look at that branch as soon as I find time. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Hmm, it seems like that landed in the project-local repository from > which GenericSetup originally sprang, but *after* GenericSetup landed in > CMF's repository. I'm attaching the patch: > > - It uses the '_notes' field both to create an OFS.Image.File log of > import runs, as well as to display at the bottom of the "Import" > tab. > > - It echoes logged messages to zLOG. > > - It expands ISetupContext's API with methods 'note', 'listNotes', > and 'clearNotes'. Stock implementations of ths API are in a new > 'SetupContextBase' class. > > Note that the patch doesn't apply cleanly to the GenericSetup trunk; > I'll have to work out why if we chose to land it. OK, I've landed it (it was easier than I expected) on a new branch: http://svn.zope.org/CMF/branches/tseaver-resync_GenericSetup Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDezAb+gerLs4ltQ4RAjWNAKCOD/7e5/y20NpnbMF4xb+Ips/9BgCg2tpR dYQ7yobSUo7gGVfiY3o16f8= =kh7K -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yuppie wrote:
> Hi Tres!
>
>
> Tres Seaver wrote:
>
>> Jens Vagelpohl wrote:
>>
>>> On 15 Nov 2005, at 14:24, yuppie wrote:
>>>
The notes should be logged *and* used for reporting in the ZMI.
Implementation:
I'm no logging expert, so I might well be missing something. The
state of the art seems to be using the Python logging package (PEP
282). Is it possible to use that framework for reporting as well? It
doesn't look like that.
Replacing the 'note' method in ISetupContext with a more logger like
API and sending the notes to the Python logger *and* to TTW reports
might be the way to go.
>>>
>>>
>>> There could be a "multiplexer" that logs to the standard Zope event log
>>> *and* keeps the messages in a memory buffer to be displayed in the
>>> browser. This could be done in a separate class or a logging API could
>>> be added to ISetupContext. Should be easy to do, really.
>>
>>
>> I *think* the current setup tool creates a text file with log messages
>> in it, and stores that file inside the tool.
>
>
> Couldn't find anything like that in the setup tool. It collects the
> messages returned by handlers, passes them around and forgets them after
> the request is finished. The _notes list of the setup context is ignored
> completely by the tool.
Hmm, it seems like that landed in the project-local repository from
which GenericSetup originally sprang, but *after* GenericSetup landed in
CMF's repository. I'm attaching the patch:
- It uses the '_notes' field both to create an OFS.Image.File log of
import runs, as well as to display at the bottom of the "Import"
tab.
- It echoes logged messages to zLOG.
- It expands ISetupContext's API with methods 'note', 'listNotes',
and 'clearNotes'. Stock implementations of ths API are in a new
'SetupContextBase' class.
Note that the patch doesn't apply cleanly to the GenericSetup trunk;
I'll have to work out why if we chose to land it.
>> I would prefer to maintain
>> the data persistently, rather than in RAM; the API for that could be
>> extended, of course.
>
>
> Why would you prefer persistent reports? Wouldn't it be sufficient to
> have the messages in the event log?
Having the log file present in the tool makes it possible to review what
happened without having filesystem access, which was importante for the
customer whose project inspired the non-CMF-specific GenericSetup.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDeyi5+gerLs4ltQ4RAkmOAJ0YDoKjTsJWoYdfeNnmSFjjt5bngQCfRVVH
wt7dJmn0rRihR1EFZ5PVEV8=
=ym+y
-END PGP SIGNATURE-
Index: context.py
===
RCS file: /usr/local/cvsroot/Products/GenericSetup/context.py,v
retrieving revision 1.2
retrieving revision 1.5
diff -u -r1.2 -r1.5
--- context.py 11 Aug 2005 21:41:36 - 1.2
+++ context.py 23 Aug 2005 21:32:01 - 1.5
@@ -42,8 +42,50 @@
from interfaces import IImportContext
from permissions import ManagePortal
+class SetupContextBase( Implicit ):
-class DirectoryImportContext( Implicit ):
+""" Base class for ISetupContext implementations.
+"""
+
+security = ClassSecurityInfo()
+def __init__(self, site):
+
+self._site = site
+self._messages = []
+
+security.declareProtected( ManagePortal, 'getSite' )
+def getSite(self):
+
+""" See ISetupContext.
+"""
+return aq_self(self._site)
+
+security.declareProtected( ManagePortal, 'note' )
+def note(self, component, message):
+
+""" See ISetupContext.
+"""
+import zLOG
+zLOG.LOG('GenericSetup', zLOG.INFO, '%s: %s' % (component, message))
+self._messages.append((component, message))
+
+security.declareProtected( ManagePortal, 'listNotes' )
+def listNotes(self):
+
+""" See ISetupContext.
+"""
+return self._messages[:]
+
+security.declareProtected( ManagePortal, 'clearNotes' )
+def clearNotes(self):
+
+""" See ISetupContext.
+"""
+self._messages[:] = []
+
+InitializeClass(SetupContextBase)
+
+class DirectoryImportContext( SetupContextBase ):
implements(IImportContext)
@@ -55,19 +97,11 @@
, should_purge=False
, encoding=None
):
-
-self._site = aq_parent( aq_inner( tool ) )
+SetupContextBase.__init__( self, aq_parent( aq_inner( tool ) ) )
self._profile_path = profile_path
self._should_purge = bool( should_purge )
self._encoding = encoding
-security.declareProtected( ManagePor
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
Hi Chris! Chris Withers wrote: Jens Vagelpohl wrote: There could be a "multiplexer" that logs to the standard Zope event log *and* keeps the messages in a memory buffer to be displayed in the browser. This could be done in a separate class or a logging API could be added to ISetupContext. Should be easy to do, really. Well, this is all supported by the logging module ;-) You can define a new log handler just for the duration of the process and then remove it. Have a look at MailingLogger's SummarisingLogger for ideas. Give it a go and let me know where the code is if you want me to take a look, I've got to know and love python's logging module quite well ;-) I had a quick look at MailingLogger, but it seems to do something different. We need 'per request' reports to give instant feedback in the setup tool. The logging module is not aware of requests, so I can't see an easy way to make sure the log handler collects only messages for a specific request. Or am I missing something? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
Hi Tres! Tres Seaver wrote: Jens Vagelpohl wrote: On 15 Nov 2005, at 14:24, yuppie wrote: The notes should be logged *and* used for reporting in the ZMI. Implementation: I'm no logging expert, so I might well be missing something. The state of the art seems to be using the Python logging package (PEP 282). Is it possible to use that framework for reporting as well? It doesn't look like that. Replacing the 'note' method in ISetupContext with a more logger like API and sending the notes to the Python logger *and* to TTW reports might be the way to go. There could be a "multiplexer" that logs to the standard Zope event log *and* keeps the messages in a memory buffer to be displayed in the browser. This could be done in a separate class or a logging API could be added to ISetupContext. Should be easy to do, really. I *think* the current setup tool creates a text file with log messages in it, and stores that file inside the tool. Couldn't find anything like that in the setup tool. It collects the messages returned by handlers, passes them around and forgets them after the request is finished. The _notes list of the setup context is ignored completely by the tool. I would prefer to maintain the data persistently, rather than in RAM; the API for that could be extended, of course. Why would you prefer persistent reports? Wouldn't it be sufficient to have the messages in the event log? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: logging/reporting framework for GenericSetup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > > On 15 Nov 2005, at 14:24, yuppie wrote: > >> The notes should be logged *and* used for reporting in the ZMI. >> >> >> Implementation: >> >> I'm no logging expert, so I might well be missing something. The >> state of the art seems to be using the Python logging package (PEP >> 282). Is it possible to use that framework for reporting as well? It >> doesn't look like that. >> >> Replacing the 'note' method in ISetupContext with a more logger like >> API and sending the notes to the Python logger *and* to TTW reports >> might be the way to go. > > > There could be a "multiplexer" that logs to the standard Zope event log > *and* keeps the messages in a memory buffer to be displayed in the > browser. This could be done in a separate class or a logging API could > be added to ISetupContext. Should be easy to do, really. I *think* the current setup tool creates a text file with log messages in it, and stores that file inside the tool. I would prefer to maintain the data persistently, rather than in RAM; the API for that could be extended, of course. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDekyJ+gerLs4ltQ4RApNNAKCMFTWqwLFrhl3618ecitJPQYB8zwCgkMhT k0O0Ef4I2DTQhHMactiF/CM= =NOSF -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
