Re: [log4perl-devel] modules logging into seperate logfiles

[Jim C. <jc...@di...>]

Mike Schilli wrote:

>There's currently no way in Log::Log4perl to load more than one config file
>or to append configuration statements to a loaded configuration. This could
>be changed, however, if we find a proper way of dealing with the following
>implications:
>
>The big problem with having libraries add their share to the L4P configuration
>is that there's no easy way of preventing them from stepping on each
>other's feet. What if lib A defines an appender named "File" and lib B
>defines a different appender under the same name? What if the main application
>wants to take control over lib X's L4P configuration? How could lib X
>possibly know what kind of application it is going to run in and what the
>l4p configuration requirements are?
>
>Ideas?
>
>-- Mike
>
>
>  
>
It strikes me that this problem is not  Log4perls responsibility.

Consider it as similar to C #include;

# include "macros.h";    /* which defines foo() amongst other things */
/* now alter the standard foo macro, for our own purposes */
#undef foo
#define foo(a,b)   bar(a,b)

this isnt the best way to handle all such situations, but its certainly 
usefull sometimes.


# strawman include syntax - it should 'be' a function, but it can look 
like an assignment.

# baseline config - not automatically used - done explicitly by user.
log4perl.include  =  X-subsys-logging-config
log4perl.include  =  Y-subsys-logging-config

# testing-config - overrides etc..
log4perl.include  =  X-subsys-logging-config-test-overrides
log4perl.include  =  Y-subsys-logging-config-test-overrides

# now further override selected pieces.
log4perl.category.X.foo = INFO
log4perl.category.Y.bar = INFO


By doing this, each subsystem can define its 'typical' usage, and 
provide several
useful override-files, which can be selectively used by the main script.

# we can even control reporting/dieing/etc of such overrides
log4perl.include.override = warn