Re: [log4perl-devel] should Log::Log4perl::Config::config_read ca ll die ?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

lei...@hp... wrote:
> well I really dont think I have temporal bandwidth for this (3 children
> under 4 - get the picture), but assuming I can get everyone (including the
> wife) into bed early one weekend, I could have a bash.

Yikes, and I thought I had it tough, only 1 preschooler.  Well don't 
feel obligated, I was just trying to empower you not guilt-trip you.

> But I'd need to know what kind of backwards compatibility would be required
> with the current behaviour?
> Would it be a new init_and_watch (say init_and_watch_with_save()...ergh)?
> or overload the init_and_watch method with another parameter ($config,
> $time, $save)

Sorry, what's "$save" for?  I think all we need is an overload like

    init_and_watch($config, $time,
                   sub { `mail -s 'bad config: $_[0]' te...@ba...` }
     )
And if the third argument isn't supplied the default is just to die.  Right?

A side note, something interesting to keep in mind is it looks like the 
log4j folks are talking about revamping the configureAndWatch, see 
Watchdogs under
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/Log4jv13Features

The include-file feature sounds interesting, I've thought about it 
myself, we should find out why log4j doesn't have it, it sounds so 
obvious.  An XML config file could probably just use external entities 
to accomplish that (but beware 
http://www.securityfocus.com/archive/1/297714/2002-10-27/2002-11-02/0)

Remember that if we're going to allow urls in an include statement 
(probably a bad idea), init_and_watch is going to bring to a halt all 
logging and program execution while it fetches the url.

> or could I go off like a blister in the sun, with a whole new paradigm ?

Ummm, I don't mean after all that to disempower you, but one of our 
goals is compatibility with log4j, so conservative changes are probably 
better ;-)

> 
> I am sure more questions will arise as I surf the code, so the more _design_
> tips now, the better
> 
> Leif Eriksen
> Developer
> HPA - IT Development
> +61 3 9217 5545
> lei...@hp...
> 
> -----Original Message-----
> From: Kevin Goess [mailto:ke...@go...]
> Sent: Thursday, May 22, 2003 1:23 AM
> To: Leif Eriksen
> Cc: wi...@da...; log...@pe...;
> log...@li...
> Subject: Re: [log4perl-devel] should Log::Log4perl::Config::config_read
> ca ll die ?
> 
> 
> Don't forget, adding features to log4perl isn't limited to Mike's 
> flashing fingers.  Patches (with unit tests) are always welcome for 
> consideration.
> 
> 
> lei...@hp... wrote:
> 
>>I have thought of the same, but Mike is busy providing meaningful new
>>features, so I decided to live with it.
>>
>>If Mike does ever want to make the change to init_and_watch, the save_old
>>functionality seems good. Another possibility I thought of is
>>1. log an 'error'-level message stating 'bad config' to the old config's
>>appender value, and no logging happens until a good config is loaded - a
>>sort of /dev/null logger takes over until a good config is found - if you
>>catch my drift. I have no idea whether this is possible.
>>
>>On another tack, and I haven't read the latest doc (we run 0.26 here) - is
>>there, or are there plans to have, an 'include'-like like ability in
> 
> config
> 
>>- I ask because I envision a logging hierarchy of config's e.g. a
> 
> corporate
> 
>>level, a division, a team etc, and we write our local config like
>>
>><>
>>include <URL/I to other config>
>>
>>log4perl.logger=...
>>#our local stuff
>><>
>>And 'other config' might include another config etc
>>
>>That way we only redefine the bits we want, but the log files also get a
>>standardised look-and-feel' by including team/division configs
>>
>>Does that make any sense?
>>
>>Leif Eriksen
>>Developer
>>HPA - IT Development
>>+61 3 9217 5545
>>lei...@hp...
>>
>>-----Original Message-----
>>From: Wiggins d'Anconia [mailto:wi...@da...]
>>Sent: Wednesday, May 21, 2003 10:59 AM
>>To: Mike Schilli
>>Cc: Leif Eriksen; log...@li...
>>Subject: Re: [log4perl-devel] should Log::Log4perl::Config::config_read
>>call die ?
>>
>>
>>Mike Schilli wrote:
>>
>>
>>>On Tue, 13 May 2003 lei...@hp... wrote:
>>>
>>>
>>>
>>>
>>>>I am not sure if this has been raised before, the sourceforge mail list
>>>>browse doesn't have a search function, so I just checked the last 100
>>>>messages.
>>>
>>>
>>>Look at the upper left corner. There's a search field and a select box
>>
>>with
>>
>>
>>>the item "This Mailing List":
>>>
>>>   http://sourceforge.net/mailarchive/forum.php?forum_id=10175
>>>
>>>
>>>
>>>
>>>>I suppose I would call this more an issue of style - I have issues with
>>>
>>any
>>
>>
>>>>library that exits on me. I would prefer a library told me 'sorry I cant
>>>>help you' and let me decide on the flow from there.
>>>>...
>>>>An eval could help - in fact there are many 'workarounds' - but I still
>>>
>>feel
>>
>>
>>>>calling die is wrong.
>>>>
>>>>Are there any plans for this behaviour to be revised in the future ??
>>>
>>>
>>>It's a trade-off to protect against people not checking the return code of
>>>init() and then wondering what's wrong. A matter of style, indeed, and
>>>negotiable.
>>>
>>>One area which is tougher to solve is with init_and_watch(). What happens
>>>if Log4perl reloads the conf file and somebody has put a syntax error
>>>in there? There's no application interaction at this point, no way to
>>>catch this error but die. I think this particular issue also drove the
>>>decision to die() on a failed init().
>>
>>
>>I had wondered about this last part (init_and_watch) while trying to 
>>bullet proof our app. Would it be possible to do something along the 
>>lines of:
>>
>>1) Store old configuration
>>2) Read new configuration
>>   a) succeeds replaces old configuration (like current)
>>   b) fails: calls handler, resumes with original configuration
>>
>>Then the author would supply 'init_and_watch' with a handler (code ref) 
>>that would be called if the new configuration couldn't be loaded. Seems 
>>like this is an easy way to alert the user, keep the app running, and 
>>still be able to log (albeit under the original configuration). Don't 
>>recall if init_and_watch is configurable from a file, that could 
>>conceivably cause some problems (aka putting a bad handler in the config 
>>file, etc.)....
>>
>>The die I don't mind on the 'init' since it can be caught and that seems 
>>to be a direction a number of modules are moving in, but the 
>>init_and_watch is an interesting issue.
>>
>>http://danconia.org
>>
>>
>>
>>**********************************************************************
>>IMPORTANT
>>The contents of this e-mail and its attachments are confidential and
> 
> intended
> 
>>solely for the use of the individual or entity to whom they are
>>addressed.  If you received this e-mail in error, please notify
>>the HPA Postmaster, pos...@hp..., then delete 
>>the e-mail.
>>
>>This footnote also confirms that this e-mail message has been swept for
>>the presence of computer viruses by MimeSweeper.  Before opening or
>>using any attachments, check them for viruses and defects.
>>
>>Our liability is limited to resupplying any affected attachments.
>>
>>HPA collects personal information to provide and market our services.
>>For more information about use, disclosure and access see our Privacy
>>Policy at www.hpa.com.au
>>**********************************************************************
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: ObjectStore.
>>If flattening out C++ or Java code to make your application fit in a
>>relational database is painful, don't do it! Check out ObjectStore.
>>Now part of Progress Software. http://www.objectstore.net/sourceforge
>>_______________________________________________
>>log4perl-devel mailing list
>>log...@li...
>>https://lists.sourceforge.net/lists/listinfo/log4perl-devel
> 
> 
> 

-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217