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

[<lei...@hp...>]

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
**********************************************************************