Menu
▾
▴
log4perl-devel
|
From: Tod H. <th...@gi...> - 2004-10-15 14:14:20
|
OK, basically what I have is mod_perl handlers, so its a bit tough to
call it a 'program', there is
no main application. I'll try to condense it down to an example handler
that should be easy to look at.
The environment is:
Mandrake Linux 10.0 official
Apache 2.0.50
Perl 5.8.5
mod_perl 1.99_16
Log::Log4perl 0.48
The attached files are:
init.pl - PerlRequired script, this runs at server startup and inits
Log4perl and loads MyTest.pm
MyTest.pm - simple modperl handler
logging.conf - sample logging configuration
vhost.conf - Apache configuration that runs all of this mess
The behaviour I get with the test is exactly consistent with my
application. I have 1 appender which I use SYNCER, so everything goes to
one log file. It appears that if I set up category 'MyTest' to 'DEBUG'
then even if rootLogger is 'FATAL' I get the messages from MyTest and
MyTest.detail, which is what I would expect (assuming they are both set
at level 'DEBUG'). But if I set MyTest to 'INFO' I don't even get the
informational message logged at that category at level INFO!!! And I
certainly never get level MyTest.detail unless MyTest is at DEBUG.
It appears that get_logger() ignores its argument and just uses package
names as categories all the time. The problem is this means I can either
get a giant blast of every debugging message my application could
possibly generate (some of the packages are fairly extensive) or NOTHING.
Furthermore even if get_logger() does ignore its argument I should STILL
get the INFO level message put out at category MyTest!!! Why do I have to
set a level of DEBUG for MyTest just to see an INFO level message???!!!
Its all making my head hurt. ;)
Thanks for getting back to me. Let me know if you see anything in my
setup that explains all this, Thanks again!
Tod Harter,
TradeDesk Software
On Thu, 14 Oct 2004, Tod Harter wrote:
>> My configuration file...
Can you also provide a code sample? Ideally, a test case of what you're
seeing and what you're expecting.
>> I've also discovered that if you set your rootLogger to say 'INFO' and
>> lower levels of the heirarchy to 'DEBUG', you NEVER get anything except
>> 'INFO'
>> level and lower from ANY part of the heirarchy. This seems to be in
>> direct contradiction of the manual and tutorials.
In this case, you'll get INFO messages in the root logger and DEBUG
messages in the 'lower levels of the hierarchy' as you've defined.
Example:
use Log::Log4perl qw(get_logger);
my $conf = q(
log4perl.rootLogger = INFO, Screen
log4perl.category.Bar.Twix = DEBUG, Screen
log4perl.appender.Screen = Log::Log4perl::Appender::Screen
log4perl.appender.Screen.layout = Log::Log4perl::Layout::SimpleLayout
);
Log::Log4perl::init(\$conf);
my $logger = get_logger("Bar::Twix");
$logger->debug("Blah");
prints two messages, one from each logger:
DEBUG - Blah
DEBUG - Blah
Can you provide a test case if you're seeing anything suspicious?
-- Mike
Mike Schilli
m...@pe...
|
|
From: Mike S. <m...@pe...> - 2004-10-15 17:36:27
|
On Fri, 15 Oct 2004, Tod Harter wrote:
> OK, basically what I have is mod_perl handlers, so its a bit tough to
> call it a 'program', there is
> no main application.
That's fine.
> The behaviour I get with the test is exactly consistent with my
> application. I have 1 appender which I use SYNCER, so everything goes to
> one log file. It appears that if I set up category 'MyTest' to 'DEBUG'
> then even if rootLogger is 'FATAL' I get the messages from MyTest and
> MyTest.detail, which is what I would expect (assuming they are both set
> at level 'DEBUG').
That's what I would expect, too. But are you sure you want to use a sub
category ".detail"? Seems like controlling the output via log levels when
calling the logging functions ($log->debug(...), $log->error(...)) would be
easier.
> But if I set MyTest to 'INFO' I don't even get the
> informational message logged at that category at level INFO!!! And I
> certainly never get level MyTest.detail unless MyTest is at DEBUG.
Your L4p configuration file seems to contain a syntax error:
log4perl MyTest.detail (dot missing)
> It appears that get_logger() ignores its argument and just uses package
> names as categories all the time.
I'd be very surprised if that was true. Here's a test case that works:
use Log::Log4perl qw(get_logger);
my $conf = q(
log4perl.rootLogger = INFO, Screen
log4perl.category.Bar = DEBUG, Screen
log4perl.category.Bar.Twix = DEBUG, Screen
log4perl.appender.Screen = Log::Log4perl::Appender::Screen
log4perl.appender.Screen.layout = Log::Log4perl::Layout::SimpleLayout
);
Log::Log4perl::init(\$conf);
my $logger = get_logger("Bar::Twix");
$logger->debug("Message to Bar::Twix");
my $barlogger = get_logger("Bar");
$barlogger->debug("Message to Bar");
Can you provide a simple case like this, confirming what you're suspecting?
-- Mike
Mike Schilli
m...@pe...
|
|
From: Tod H. <th...@gi...> - 2004-10-18 14:10:40
|
OK, here's what I've discovered in my research, using essentially your
example:
There are at least 3 different documented ways to define a logging category
1) log4perl.categoryname = ...
2) log4perl.category.categoryname = ...
3) log4perl.logger.categoryname = ...
and as well at least 2 ways of defining the root logger (maybe others
work as well....).
1) log4perl.rootLogger = ....
2) log4perl.logger = ...
Method 1 of defining a category does not work, at least not on my system!
Method 2 does work
Method 3 I haven't tested
And as for the root logger, method 1 works and method 2 may work but
doesn't seem to work in all cases, though I didn't explore that enough
to be sure
of exactly what was going on.
So the upshot is that between the manual, other pod files for Appenders,
etc, and the tutorial(s) there are some errr discrepencies.
Anyway, thanks for the help, now all I have to conquer is 'additivity'
(which it seems to me for most simple applications the default aught to
be the opposite, but whatever
thats just my personal preference). Thanks again.
>I'd be very surprised if that was true. Here's a test case that works:
>
> use Log::Log4perl qw(get_logger);
>
> my $conf = q(
> log4perl.rootLogger = INFO, Screen
> log4perl.category.Bar = DEBUG, Screen
> log4perl.category.Bar.Twix = DEBUG, Screen
> log4perl.appender.Screen = Log::Log4perl::Appender::Screen
> log4perl.appender.Screen.layout = Log::Log4perl::Layout::SimpleLayout
> );
>
> Log::Log4perl::init(\$conf);
>
> my $logger = get_logger("Bar::Twix");
> $logger->debug("Message to Bar::Twix");
>
> my $barlogger = get_logger("Bar");
> $barlogger->debug("Message to Bar");
>
>Can you provide a simple case like this, confirming what you're suspecting?
>
>-- Mike
>
>Mike Schilli
>m...@pe...
>
>
|
|
From: Mike S. <m...@pe...> - 2004-10-26 05:51:55
|
On Mon, 18 Oct 2004, Tod Harter wrote: > There are at least 3 different documented ways to define a logging category > > 1) log4perl.categoryname = ... > 2) log4perl.category.categoryname = ... > 3) log4perl.logger.categoryname = ... "logger" and "category" are indeed synonyms and can be used interchangeably. But I'd be surprised if 1) worked. > and as well at least 2 ways of defining the root logger (maybe others > work as well....). > > 1) log4perl.rootLogger = .... > 2) log4perl.logger = ... Correct. And even log4perl.category will work. That's TMTOWTDI. > Method 1 of defining a category does not work, at least not on my system! > Method 2 does work > Method 3 I haven't tested Can you point out where 1) is endorsed in the docs? > And as for the root logger, method 1 works and method 2 may work but > doesn't seem to work in all cases, though I didn't explore that enough > to be sure > of exactly what was going on. If you find cases which don't work, I'd be very interested to hear about them. > Anyway, thanks for the help, now all I have to conquer is 'additivity' > (which it seems to me for most simple applications the default aught to > be the opposite, but whatever > thats just my personal preference). That's a topic which is discussed controversly in L4j land as well. It's just a default setting though, and it can be adjusted to your preferences easily. -- Mike Mike Schilli m...@pe... |
|
From: Tod H. <th...@gi...> - 2004-10-26 12:57:15
|
Mike Schilli wrote: >On Mon, 18 Oct 2004, Tod Harter wrote: > > > >>There are at least 3 different documented ways to define a logging category >> >>1) log4perl.categoryname = ... >>2) log4perl.category.categoryname = ... >>3) log4perl.logger.categoryname = ... >> >> > >"logger" and "category" are indeed synonyms and can be used interchangeably. >But I'd be surprised if 1) worked. > > OK, maybe #1 is just a special case for the root logger. >>And as for the root logger, method 1 works and method 2 may work but >>doesn't seem to work in all cases, though I didn't explore that enough >>to be sure >>of exactly what was going on. >> >> > >If you find cases which don't work, I'd be very interested to hear about >them. > > I'll see if I can come up with a test case. log4perl.oneMessagePerAppender = 1 didn't seem to work, hmmm. It seems to me that config file parsing ignores a lot of errors. It would be really nice to be able to have either a logging configuration checker or a 'pedantic' mode that throws an error on anything non-kosher it sees in the config file. Overall its a pretty nice system, though if I'd have designed L4J I think I'd have stuck more to a philosophy of 'what not how' in terms of configuration (IE why not have the directives organized in such a way as to describe where log file entries would end up as opposed to how the handlers are stacked) but thats neither here nor there... Keep up the good work, its appreciated. |
|
From: Kevin G. <ke...@go...> - 2004-10-26 15:16:19
|
Tod Harter wrote: > It seems to me that config file parsing ignores a lot of errors. It > would be really nice to be able to have either a logging > configuration checker or a 'pedantic' mode that throws an error on > anything non-kosher it sees in the config file. That's a built-in problem with a properties-style configuration file--the format is open enough where it's hard to put constraints on the file. If you want better configuration error-checking, try the xml-style configuration file. Then you can check it against the DTD before you run it, and that will catch a lot of possible errors. -- Happy Trails . . . Kevin M. Goess (and Anne and Frank) 904 Carmel Ave. Albany, CA 94706 (510) 525-5217 |
|
From: Tod H. <th...@gi...> - 2004-10-27 17:33:55
|
Kevin Goess wrote: > > > Tod Harter wrote: > >> It seems to me that config file parsing ignores a lot of errors. It >> would be really nice to be able to have either a logging >> configuration checker or a 'pedantic' mode that throws an error on >> anything non-kosher it sees in the config file. > > > That's a built-in problem with a properties-style configuration > file--the format is open enough where it's hard to put constraints on > the file. > > If you want better configuration error-checking, try the xml-style > configuration file. Then you can check it against the DTD before you > run it, and that will catch a lot of possible errors. > Yeah, they're somewhat of a PITA to write, but that would probably be more reliable. I suppose I could write a checker that builds an XML conf file from a standard one. <digs out reference manuals...> |
×
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