Re: Running under mod_perl (was Re: [log4perl-devel] Can't call method "PRINT" on an undefined value)

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

Mike Schilli wrote:

>William McKee wrote on 1/13/2004, 11:30 AM:
>
> > How about another feature? Would there be a way to have this module
> > append configuration info when init is called by two separate
> > applications?
>
>I seem to remember that this has been suggested here before :). We've 
>been playing with this idea, but kind of stepped away from it because 
>it's too easy for different applications to step on each others feet (by 
>accidently using the same appender names etc.) without any effective 
>means to prevent that yet. And some day, we're gonna tackle this "Logger 
>Repository" issue, I promise :).
>
>  
>
FWIW, I think that would be me.
BTW - are there better / more searchable archives than at
http://sourceforge.net/mailarchive/forum.php?forum_id=10175&max_rows=25&style=flat&viewmonth=200310&viewday=22

Jim Cromie wrote on 10/22/2003, 10:32 PM:

 > pls accept this patch to make pre 0.38 init available as initAdd.
 > I need it to restore the ability of Log::Log4perl::AutoCategorize to
 > play nice with others.

+###########################################
+sub initAdd {
+###########################################
+    # make pre-0.38 init() behavior available for those who need it
+    return _init(@_);
+}

Not sure why you're not using l4p:Config::_init() in l4p:AutoCategorize? 
Does the underscore scare you  ?



Mike Schilli wrote:

> Jim Cromie wrote on 10/23/2003, 5:41 AM:
>
> > But its not my usage per se, its a recommendation to users who
> > would use AutoCategorize on some modules and not others.
> >
> > Telling them to use Log::Log4perl::Config->_init()
> > *does* just work however, and I can live with that.
>
> Not sure I understand why one would need to 'add' configuration parts 
> instead of a complete reset&load. Feeding parts to the configuration 
> which are highly dependent on previously fed parts sounds error-prone 
> to me. What's the rationale?
>
>  
>
The idea was to improve coexistence of both approaches in a larger 
application.

It would seem possible that a project would have;

* an EasyUser.pm,         which would use :easy logging and easy_init(),
* a StandardUser.pm,     which would use the more explicit API
* an AutoCatUser.pm,    which uses my module

my test: t/09_coexist_easy.t  uses 1,3 together in the same executable,
and they 'share' a single config, which contains whatever easy_init()
put there, and my config, slapped in with it.

That test now uses this code snippet, ie l4p::Config::_init,
to avoid resetting easy_init()s config-initializations.