You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by ms...@aol.com on 2002/10/05 05:35:40 UTC

Late Instantiation of Appenders

Hi all,

are log4j appenders instantiated at initialization time or when they're triggered for the first time? I'm assuming the former. Background is, we've had a request on the Log4perl mailing list to defer instantiation for reasons listed below. Since we want to keep Log4perl compatible with log4j, I'd like to get your opinion on it. Please let me know ... 

Original posting:
http://sourceforge.net/mailarchive/forum.php?thread_id=1136366&forum_id=10175

"Is there a reason that all the appenders listed in the config data are instantiated at start-up?

I ask because I came across a problem when Log4perl is used
in a context where there is a single config file slurped and parsed by multiple processes with different permissions sets.

Specifically, if my program is running as "joeuser" and the config file contains an appender for use by "root"-only processes to log stuff to /super/secret/logfiles via Log::Dispatch::File, the first process will always die as soon as it calls &get_logger.

"joeuser" doesn't have write permissions on the logfiles directory but the File widget will try to open a handle as soon as it is created and when it fails -- I find this sort of thing a bit annoying on principle but it's not a log4perl thing -- bring the whole program down with it.

  
-- Mike

############################
# Mike Schilli             #
# log4perl@perlmeister.com #
# http://perlmeister.com   #
# log4perl.sourceforge.net #
############################


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Late Instantiation of Appenders

Posted by Ceki Gülcü <ce...@qos.ch>.
Sharing of the config pattern was not a consideration in Configurator 
implementations. Appenders listed in the config file (but only those which 
are referenced by loggers) are instantiated when the config file is parsed 
because that is the a simple way to do it. In the absence of a good reason 
simplicity is usually the strategy.

At 23:35 04.10.2002 -0400, mschilli1@aol.com wrote:
>Hi all,
>
>are log4j appenders instantiated at initialization time or when they're 
>triggered for the first time? I'm assuming the former. Background is, 
>we've had a request on the Log4perl mailing list to defer instantiation 
>for reasons listed below. Since we want to keep Log4perl compatible with 
>log4j, I'd like to get your opinion on it. Please let me know ...
>
>Original posting:
>http://sourceforge.net/mailarchive/forum.php?thread_id=1136366&forum_id=10175
>
>"Is there a reason that all the appenders listed in the config data are 
>instantiated at start-up?
>
>I ask because I came across a problem when Log4perl is used
>in a context where there is a single config file slurped and parsed by 
>multiple processes with different permissions sets.
>
>Specifically, if my program is running as "joeuser" and the config file 
>contains an appender for use by "root"-only processes to log stuff to 
>/super/secret/logfiles via Log::Dispatch::File, the first process will 
>always die as soon as it calls &get_logger.
>
>"joeuser" doesn't have write permissions on the logfiles directory but the 
>File widget will try to open a handle as soon as it is created and when it 
>fails -- I find this sort of thing a bit annoying on principle but it's 
>not a log4perl thing -- bring the whole program down with it.
>
>
>-- Mike
>
>############################
># Mike Schilli             #
># log4perl@perlmeister.com #
># http://perlmeister.com   #
># log4perl.sourceforge.net #
>############################
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>

--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>