Menu
▾
▴
log4perl-devel
|
From: Jim C. <jc...@di...> - 2003-10-23 05:39:52
Attachments:
patch-log4perl
|
hi folks,
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.
Specifically, tests: 09_todo_coexist (not really todo anymore), and
10_multi_pack.t
verify its ability to be used in part of a project, and to interoperate
with other parts
which are using the standard Log::Log4perl.
If they make it in 0.39, Ill follow with an 0.03
Also:
* I changed Changes to reflect that not only easy_init, but all its
friends, do the reset.
* I didnt document initAdd, cuz no mention was made of reset in main pod,
so theres no good context to explain the difference.
* initAdd creates one more way to alter a config at runtime. I dont
think its a good way
to do so repeatedly. In particular, I think mixing it and
init-and-watch() would be a bad
idea, unless youre *careful* to re-add config changes you made dynamically.
* you may prefer expose only Log::Log4perl::Config::initAdd, not in
main class,
but that felt a bit too secret.
FMITYWTK:
# note the use time init, if you want it.
use Log::Log4perl::AutoCategorize ( alias => 'myLogger',
initfile => 'log-conf', # no effect here, cuz reset
inside easy_init
);
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init ({ level => $INFO,
file => "out.09_todo_coexist_easy",
layout => 'F=%F{1} M=%M L=%L: Cat=%c %m%n',
});
# in Log::Log4perl-0.38, easy_init now resets config, so we re-add it here
Log::Log4perl->initAdd ('log-conf');
# these also work
#Log::Log4perl::Config->initAdd ('log-conf');
#Log::Log4perl::AutoCategorize->initAdd ('log-conf');
|
|
From: Mike S. <msc...@ao...> - 2003-10-23 13:36:06
|
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
Mike Schilli
m...@pe...
|
|
From: Jim C. <jc...@di...> - 2003-10-24 19:42:43
|
Mike Schilli wrote:
>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 :) ?
>
>
>
heh. that would work.
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.
|
|
From: Mike S. <msc...@ao...> - 2003-10-24 21:24:05
|
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? -- -- Mike Mike Schilli m...@pe... |
|
From: Jim C. <jc...@di...> - 2003-10-24 23:22:26
|
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.
use Log::Log4perl::AutoCategorize ( alias => 'myLogger',
initfile => 'log-conf', # no effect here
);
use Log::Log4perl qw(:easy);
myLogger->easy_init ({ level => $INFO,
file => "out.09_coexist_easy_easyout",
layout => 'F=%F{1} M=%M L=%L: Cat=%c %m%n',
});
# add initialization wo resetting
Log::Log4perl::Config->_init('log-conf');
Im perfectly happy with this solution - and it implicitly flags the
situation as less than ideal. As a project gets larger, they probably
want to switch from Easy to Standard anyway - but Im not above
luring them in with seductive appeal of Laziness :-D
I agree that it would be easy to construct problematic configs this way,
trashing earlier config by respesifying those items, and probably hard
to debug.
I will be adding some caveats to that effect in my upcoming 0.03 release.
BTW - it was your feedback wrt interoperation/coexistence that started
this ;-)
thx again for a very cool module.
|
|
From: Mike S. <msc...@ao...> - 2003-10-25 19:45:59
|
Jim Cromie wrote on 10/24/2003, 3:00 PM: > * 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, As you've already mentioned, having all three of them active at once without preventing them from stepping on each other's toes could cause some hard-to-debug errors. However, what we'll have in one of the upcoming l4p releases is the notion of "logger repositories", separate compartments of l4p configurations, which work independently of each other within the same executable. Stay tuned ... -- -- Mike Mike Schilli m...@pe... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X