Re: [Zope-dev] Logging for ZScheduler?
I've created a STUPID_LOG helper product, called FrozenLogger, that does the
minimum necessary for me to create a STUPID_LOG_FILE at my account at CodeIt
Computing (where lack of telnet keeps me from setting environment
variables).
http://www.zope.org/Members/lstaffor/FrozenLogger
The core of this is:
from Globals import data_dir
if os.environ.has_key('STUPID_LOG_FILE'):
pass
else:
os.environ['STUPID_LOG_FILE']=string.join((data_dir,'FrozenLogger.txt'),'/')
It works for me at CodeIt, but I doubt if it's general enough for some of
the Zope virtual hosting schemes I've read about here. Let me know how your
mileage varies.
-- Loren
- Original Message -
From: "Stuart 'Zen' Bishop" <[EMAIL PROTECTED]>
To: "Loren Stafford" <[EMAIL PROTECTED]>
Cc: "Loren Stafford" <[EMAIL PROTECTED]>; "zope-dev"
<[EMAIL PROTECTED]>
Sent: June 15, 2000 01:57 PM
Subject: RE: [Zope-dev] Logging for ZScheduler?
> On Thu, 15 Jun 2000, Loren Stafford wrote:
>
> > Aha! Even tho a cohosted account might not be able to modify the source
of
> > the Zope implementation directly, installing a CustomLog product could
do so
> > indirectly, by importing ZLogger and modifying the loggers tuple. To
know
> > where to write the log file, CustomLog would have to either know or be
> > configurable enough to adapt to the ISP's Zope configuration. I suppose
an
> > absolute path property would be suffient. An ISP could preconfigure and
> > preinstall the CustomLog product for all users, or each user could do
it.
>
> Dump it Globals.data_dir unless a given environment variable is set.
>
> (Sorry bout the double reply)
>
> --
> Stuart Bishop Work: [EMAIL PROTECTED]
> Senior Systems Alchemist Play: [EMAIL PROTECTED]
> Computer Science, RMIT University
>
>
> ___
> Zope-Dev maillist - [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope )
>
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging for ZScheduler?
"Phillip J. Eby" <[EMAIL PROTECTED]> > > At 01:58 PM 6/15/00 +1000, Stuart 'Zen' Bishop wrote: > > > > Its not a problem with ZScheduler, it a problem that no one has > > written a plug-in logging system that is good enough for what > > you are trying to do. The existing zLOG API is fine (well - it > > could be better), but just needs someone to write the relevant > > modules. Hmm... I think I'll > > add a section to the Interfaces Wiki... > > Hm... this could work well with Observer->Observable, too. > Imagine firing ObservableEvents, and subscribing a "Log" object > to them... Ayup, logging is one of the classic instances of that pattern. The problem with using Observer for logging, especially in a fine-grained way, is that the dependency arrows point the "wrong way" -- the logger object needs to register as an Observer of many Subjects, but has no good way to find them all. The typical solution is to add an intermediate observer to all the containers, who watches the add and remove operations, and then either notifies the logger of new subscriptions it should perform, or performs them on behalf of the logger. Tres. -- === Tres Seaver[EMAIL PROTECTED] Digital Creations"Zope Dealers"http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging for ZScheduler?
Loren Stafford wrote: > > Not knowing what subsystem was for, I just filled it with __name__. So a log > entry looks like this: > > -- > 2000-06-14T20:05:22 INFO(0) Products.ZScheduler.Loggerr > Trigger event: http://eagle:8080/zev3 > Trigger time: 1970/12/31 16:00:00 US/Pacific > Bang! > > -- This is a fine usage of subsystem. The idea is to identify which component logged the message. __name__ does that pretty well. In the past, we've just used a simple string, like 'zdeamon'. Does anyone object to making __name__ the convention? I like it. It lets you find the object in the code and tell you where to set breakpoints in the debugger pretty clearly without having to hunt. But perhaps there is something more interesting in some cases, like the physical location of an object in the database if it is persistent. I kinda like: subsys = string.join(self.getPhysicalPath(), '/') + ":" + `self` This is probably 2.2 specific. -- -Michel Pelletier http://www.zope.org/Members/michel/MyWiki Visit WikiCentral for the latest Zen: http://www.zope.org/Members/WikiCentral ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Logging for ZScheduler?
Not knowing what subsystem was for, I just filled it with __name__. So a log entry looks like this: -- 2000-06-14T20:05:22 INFO(0) Products.ZScheduler.Loggerr Trigger event: http://eagle:8080/zev3 Trigger time: 1970/12/31 16:00:00 US/Pacific Bang! -- If you need to parse this, you can determine that it came from ZScheduler, you can determine which event was triggered, and you can see the output of the event, if any (Bang!, in this case). Is that good enough for any applications you have in mind? -- Loren > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of Stuart 'Zen' Bishop > Sent: Thursday, June 15, 2000 13:52 > To: Loren Stafford > Cc: Loren Stafford; zope-dev > Subject: RE: [Zope-dev] Logging for ZScheduler? > > > On Thu, 15 Jun 2000, Loren Stafford wrote: > > > > It would be a good idea if there was a field in the ZEvent > that defined > > > the subsystem used in the zLOG call. > > > > I didn't follow your point here. By "subsytem" do you mean > which logger in > > the loggers tuple? Then do you mean that different ZEvents could log to > > different loggers? Why would this be a "good idea", I mean, do > you have a > > use case in mind? > > from zLOG.py: > def LOG(subsystem, severity, summary, detail='', error=None, > reraise=None): > > The first argument specifies a subsystem, which is passed to the logging > implementation. A logging subsystem may choose to ignore log messages > from particular subsystems, or perform special actions (eg. if > a critical error has occured in the ZScheduler subsystem, page the > sysadmin). By allowing an individual ZEvent to override the > subsystem reported, you can gain even more control. > > -- > Stuart Bishop Work: [EMAIL PROTECTED] > Senior Systems Alchemist Play: [EMAIL PROTECTED] > Computer Science, RMIT University > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging for ZScheduler?
- Original Message - From: "Loren Stafford" <[EMAIL PROTECTED]> To: "Phillip J. Eby" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Loren Stafford" <[EMAIL PROTECTED]> Cc: "zope-dev" <[EMAIL PROTECTED]> Sent: Thursday, June 15, 2000 4:40 PM Subject: RE: [Zope-dev] Logging for ZScheduler? > Cool! Then the logging operation would become a part of the scheduled event > thread and transaction instead of part of the Dispatcher's thread (a > possibly transaction). I'll have to think about the implications of that. > > Where is Observer->Observable in the development plan? ZPatterns 0.4? Actually, it's in Zope 2.2... It was checked into CVS a few days back. Kevin ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Logging for ZScheduler?
On Thu, 15 Jun 2000, Loren Stafford wrote: > > It would be a good idea if there was a field in the ZEvent that defined > > the subsystem used in the zLOG call. > > I didn't follow your point here. By "subsytem" do you mean which logger in > the loggers tuple? Then do you mean that different ZEvents could log to > different loggers? Why would this be a "good idea", I mean, do you have a > use case in mind? from zLOG.py: def LOG(subsystem, severity, summary, detail='', error=None, reraise=None): The first argument specifies a subsystem, which is passed to the logging implementation. A logging subsystem may choose to ignore log messages from particular subsystems, or perform special actions (eg. if a critical error has occured in the ZScheduler subsystem, page the sysadmin). By allowing an individual ZEvent to override the subsystem reported, you can gain even more control. -- Stuart Bishop Work: [EMAIL PROTECTED] Senior Systems Alchemist Play: [EMAIL PROTECTED] Computer Science, RMIT University ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Logging for ZScheduler?
On Thu, 15 Jun 2000, Loren Stafford wrote: > Aha! Even tho a cohosted account might not be able to modify the source of > the Zope implementation directly, installing a CustomLog product could do so > indirectly, by importing ZLogger and modifying the loggers tuple. To know > where to write the log file, CustomLog would have to either know or be > configurable enough to adapt to the ISP's Zope configuration. I suppose an > absolute path property would be suffient. An ISP could preconfigure and > preinstall the CustomLog product for all users, or each user could do it. Dump it Globals.data_dir unless a given environment variable is set. (Sorry bout the double reply) -- Stuart Bishop Work: [EMAIL PROTECTED] Senior Systems Alchemist Play: [EMAIL PROTECTED] Computer Science, RMIT University ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Logging for ZScheduler?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of Phillip J. Eby > Sent: Wednesday, June 14, 2000 21:21 > To: [EMAIL PROTECTED]; Loren Stafford > > At 01:58 PM 6/15/00 +1000, Stuart 'Zen' Bishop wrote: > > > >Its not a problem with ZScheduler, it a problem that no one has written > >a plug-in logging system that is good enough for what you are trying to > >do. The existing zLOG API is fine (well - it could be better), but just > >needs someone to write the relevant modules. Hmm... I think I'll > >add a section to the Interfaces Wiki... > > Hm... this could work well with Observer->Observable, too. > Imagine firing > ObservableEvents, and subscribing a "Log" object to them... Cool! Then the logging operation would become a part of the scheduled event thread and transaction instead of part of the Dispatcher's thread (a possibly transaction). I'll have to think about the implications of that. Where is Observer->Observable in the development plan? ZPatterns 0.4? -- Loren ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Logging for ZScheduler?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of Stuart 'Zen' Bishop > Sent: Wednesday, June 14, 2000 20:58 > To: Loren Stafford > > On Wed, 14 Jun 2000, Loren Stafford wrote: > > > I need some advise for designing a flexible system for logging the > > activities of scheduled events. > > You could just call Zope's logging system and move it out of the > scope of your product. Have a look at zLOG.py or LOGGING.txt > if you havn't already. Means people can extend their logging system > to their hearts content with no effect on your product. ZScheduler already uses zLOG.LOG. I guess I forgot that it permits implementations other than stupid_log. So I guess ZScheduler is as flexible as can be, given the current API. > > > But ZScheduler also needs to be ISP independent. That is, you > should have > > complete scheduling capabilities for your cohosted Zope > applications without > > having to call up the ISP and ask for system configuration changes. > This could be achieved with a seperate product. A product that > ties into Zope's logging infrastructure and allows viewing the > log files through the web. All it would have to do is append itself to the > ZLogger.loggers tuple, and the interface is pretty trivial. And of course, > it means that other products can use it without modification > (Logger product, > Zope itself etc.) and can be extended as required without having to > submit patches to you for inclusion in ZScheduler. Aha! Even tho a cohosted account might not be able to modify the source of the Zope implementation directly, installing a CustomLog product could do so indirectly, by importing ZLogger and modifying the loggers tuple. To know where to write the log file, CustomLog would have to either know or be configurable enough to adapt to the ISP's Zope configuration. I suppose an absolute path property would be suffient. An ISP could preconfigure and preinstall the CustomLog product for all users, or each user could do it. > > It would be a good idea if there was a field in the ZEvent that defined > the subsystem used in the zLOG call. > I didn't follow your point here. By "subsytem" do you mean which logger in the loggers tuple? Then do you mean that different ZEvents could log to different loggers? Why would this be a "good idea", I mean, do you have a use case in mind? -- Thanks -- Loren ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging for ZScheduler?
At 12:42 PM 6/15/00 -0400, Shane Hathaway wrote: > >Agreed; I see this as by far the best approach. It's a tried and true >pattern. > Not only that, but it gives you extremely fine-grained control over what you do and don't log. And, if the other events like adds and deletes on folders are in place, you can make a monitoring object that notices when new things are added, and subscribes the logger to them... ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging for ZScheduler?
"Phillip J. Eby" wrote: > > At 01:58 PM 6/15/00 +1000, Stuart 'Zen' Bishop wrote: > > > >Its not a problem with ZScheduler, it a problem that no one has written > >a plug-in logging system that is good enough for what you are trying to > >do. The existing zLOG API is fine (well - it could be better), but just > >needs someone to write the relevant modules. Hmm... I think I'll > >add a section to the Interfaces Wiki... > > Hm... this could work well with Observer->Observable, too. Imagine firing > ObservableEvents, and subscribing a "Log" object to them... Agreed; I see this as by far the best approach. It's a tried and true pattern. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging for ZScheduler?
At 01:58 PM 6/15/00 +1000, Stuart 'Zen' Bishop wrote: > >Its not a problem with ZScheduler, it a problem that no one has written >a plug-in logging system that is good enough for what you are trying to >do. The existing zLOG API is fine (well - it could be better), but just >needs someone to write the relevant modules. Hmm... I think I'll >add a section to the Interfaces Wiki... Hm... this could work well with Observer->Observable, too. Imagine firing ObservableEvents, and subscribing a "Log" object to them... ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging for ZScheduler?
On Wed, 14 Jun 2000, Loren Stafford wrote: > I need some advise for designing a flexible system for logging the > activities of scheduled events. You could just call Zope's logging system and move it out of the scope of your product. Have a look at zLOG.py or LOGGING.txt if you havn't already. Means people can extend their logging system to their hearts content with no effect on your product. > But ZScheduler also needs to be ISP independent. That is, you should have > complete scheduling capabilities for your cohosted Zope applications without > having to call up the ISP and ask for system configuration changes. > ZScheduler partially achieves this level of independence, by eliminating the > need for cron. This could be achieved with a seperate product. A product that ties into Zope's logging infrastructure and allows viewing the log files through the web. All it would have to do is append itself to the ZLogger.loggers tuple, and the interface is pretty trivial. And of course, it means that other products can use it without modification (Logger product, Zope itself etc.) and can be extended as required without having to submit patches to you for inclusion in ZScheduler. It would be a good idea if there was a field in the ZEvent that defined the subsystem used in the zLOG call. > So, I need a more flexible structure for the logging aspect of ZScheduler. > While the ZEvent class is subclassable by users, I haven't made the > Scheduler class instantiable -- there should be only one instance -- so it's > not subclassable either, and therefore you can't override its logging > method. Do you see the problem? > Having little experience with Python and OO applications, I don't know how > others solve this problem. Can you give me any pointers? Its not a problem with ZScheduler, it a problem that no one has written a plug-in logging system that is good enough for what you are trying to do. The existing zLOG API is fine (well - it could be better), but just needs someone to write the relevant modules. Hmm... I think I'll add a section to the Interfaces Wiki... -- Stuart Bishop Work: [EMAIL PROTECTED] Senior Systems Alchemist Play: [EMAIL PROTECTED] Computer Science, RMIT University ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Logging for ZScheduler?
I need some advise for designing a flexible system for logging the activities of scheduled events. One of the motivations for developing ZScheduler was to have a platform independent means for scheduling Zope tasks. The lask of a cron on Windows platforms was a part of the problem. ZScheduler achieves this independence by using Python's threading.Wait method for all time measurement. But ZScheduler also needs to be ISP independent. That is, you should have complete scheduling capabilities for your cohosted Zope applications without having to call up the ISP and ask for system configuration changes. ZScheduler partially achieves this level of independence, by eliminating the need for cron. But, as I installed ZScheduler under my personal account at CodeIt Computing, I realized that an ISP-dependence still exists, and it has nothing to do with cron -- it has to do with the configuration of the Scheduler's logging activity. When you have a Scheduler executing applications tasks on your website behind your back, you definitely want it to keep a log of what it is doing. For ZScheduler, I chose to use the STUPID_LOG_FILE feature of Zope. However, STUPID_LOG_FILE is an environment variable. Zope accounts at CodeIt (and probably at any other Zope ISP) cannot set environmet variables. And if they could, is anyone certain how STUPID_LOG_FILE would behave in their custom cohosting adaptation of Zope? So, I need a more flexible structure for the logging aspect of ZScheduler. While the ZEvent class is subclassable by users, I haven't made the Scheduler class instantiable -- there should be only one instance -- so it's not subclassable either, and therefore you can't override its logging method. Do you see the problem? Having little experience with Python and OO applications, I don't know how others solve this problem. Can you give me any pointers? Perhaps I've identified a typical application of RIPP? -- Thanks -- Loren ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
