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

[Kevin G. <ke...@go...>]

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