log4perl-devel — Ongoing log4perl development

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

[William M. <wi...@kn...>]

On Tue, Jan 13, 2004 at 06:35:47PM -0800, Mike Schilli wrote:
> 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.

Yeah, I seem to recall that thread now that you mention it. I didn't
understand the reason for the discussion at the time but it sure makes
sense now! Ain't perspective grand?!


> And some day, we're gonna tackle this "Logger Repository" issue, I
> promise :).

How's the Logger Repository issue different from the init_once function
which you have already incanted into 0.42? Seems like they are
addressing the same issue of having calling init multiple times. I guess
the Logger Repository is a bit broader, but I don't have all the
background.


Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

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

[Mike S. <msc...@ao...>]

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 :).

-- 
-- Mike
Mike Schilli
m...@pe...

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

[Mike S. <msc...@ao...>]

Kevin Goess wrote on 1/13/2004, 8:27 AM:

 > | BTW, why won't this code work in a multi-threaded environment?

Looks like I was overzealous on this one ... generally speaking, having 
unsynchronized globals in multi-threaded code introduces race 
conditions. However, perl's 5.6+ threading model doesn't share variables 
between threads by default, so that's not an issue. And in the special 
case of the code I posted, it would probably even be ok if variables 
were shared, because worst case you would initialize L4p twice, which 
isn't the end of the world.

One thing I wanted to add for mod_perl-like multi-process environments, 
though: No matter if you use a startup handler to init() L4p or use the 
init_once() strategy (just added it to 0.42), you're very likely to have 
unsynchronized writes to logfiles.

If L4p is configured with a log file appender, and it is initialized via 
the Apache startup handler, the file handle created initially will be 
shared among all Apache processes. Similarly, with the init_once() 
approach: although every process has a separate L4p configuration, 
processes are gonna share the appender file *names* instead, effectively 
opening several different file handles on the same file.

Now, having several appenders using the same file handle or having 
several appenders logging to the same file unsynchronized, this might 
result in overlapping messages. Sometimes, this is acceptable. If it's 
not, here's two strategies:

* Use Log4perl's Synchronized appender to connect to your file 
appenders. Here's the writeup:

http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl/FAQ.html#23804

* Use a different logfile for every process like in

     #log4perl.conf
     ...
     log4perl.appender.A1.filename = sub { "mylog.$$.log" }

Hope that helps ...

-- 
-- Mike
Mike Schilli
m...@pe...

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

[William M. <wi...@kn...>]

On Tue, Jan 13, 2004 at 08:19:53AM -0800, Kevin Goess wrote:
> Mike Schilli wrote:
> | definitely the way to go for now. Hmm ... just had an idea: How about if
> | Log::Log4perl featured an init_once() method, like Apache::DBI, which
> | connects (inits) only if it doesn't have a valid connection
> | (configuration) yet?
> 
> Brilliant!  The only question I have is: why didn't we think of that before?

Perhaps because it is only needed by cgi scripts running under
Apache::Registry. It seems like modules written for modperl could run
the init just once.

How about another feature? Would there be a way to have this module
append configuration info when init is called by two separate
applications? That would allow Log4perl configurations to be kept with
their respective applications and yet run under the same logger. Or is
modifying the configuration of a running logger not suggested?

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

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

[William M. <wi...@kn...>]

On Tue, Jan 13, 2004 at 08:27:14AM -0800, Kevin Goess wrote:
> Yup, that's why you have to think in terms of one big log4perl engine
> per interpreter.  It follows from that that you'd have one big config
> file for your whole site, not separate configs for each application.
> With the flexibility of categories, it should be simple to keep the
> applications' logging behavior separate.

Oh, I hadn't come to this realization yet probably because I haven't
tried using Log4perl across multiple applications running on the same
server. This is probably also why I haven't noticed any anomalies in
calling init multiple times. Glad to know about it now before I got
further down the road of deploying modperl apps with Log4perl!

It sounds like I need to have the init called from the startup script
via a PerlRequire directive as you had suggested. I'll have to either
create a system-wide config file or write some code to pull the configs
in from my various projects.

Thanks for the info!
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

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

[Kevin G. <ke...@go...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

William McKee wrote:
| but what if I run multiple applications that use
| Log4perl? It looks like you are calling a class attribute. At startup,
| it seems like one app could initialize the object and the next would not
| initialize its logger object and run into problems.

Yup, that's why you have to think in terms of one big log4perl engine
per interpreter.  It follows from that that you'd have one big config
file for your whole site, not separate configs for each application.
With the flexibility of categories, it should be simple to keep the
applications' logging behavior separate.

| BTW, why won't this code work in a multi-threaded environment?

Mike,can you answer that one?



- --
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFABBxi4g4/Tl71vUkRAkiHAJ9DmQUsU/JrflAza2afflll6xhJbQCgmWcP
byP4U/nDClEXNdhuLtQuAbQ=
=Afuc
-----END PGP SIGNATURE-----

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

[Kevin G. <ke...@go...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Schilli wrote:
| definitely the way to go for now. Hmm ... just had an idea: How about if
| Log::Log4perl featured an init_once() method, like Apache::DBI, which
| connects (inits) only if it doesn't have a valid connection
| (configuration) yet?

Brilliant!  The only question I have is: why didn't we think of that before?

- --
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFABBqp4g4/Tl71vUkRAsyoAJwJBrCY7ZfEs8DNS1EVbQYRAP94awCffKvQ
Htaw/FZAvtSUtcIhwEwzrq0=
=HLNJ
-----END PGP SIGNATURE-----

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

[William M. <wi...@kn...>]

On Tue, Jan 13, 2004 at 01:16:16AM -0800, Mike Schilli wrote:
> Oh, and for now, something like
> 
>      use Log::Log4perl;
> 
>      unless($Log::Log4perl::Logger::INITIALIZED) {
>          Log::Log4perl->init(...);
>      }
> 
> might do the trick (at least if it's single-threaded) ...

OK, I'll add that to my code just to be on the safe side. I am
single-threaded but am running multiple processes (typical Apache
server under Linux stuff). I guess each process will have it's own
Log4perl object, but what if I run multiple applications that use
Log4perl? It looks like you are calling a class attribute. At startup,
it seems like one app could initialize the object and the next would not
initialize it's logger object and run into problems. But perhaps I'm not
grokking how you have the Log4perl system setup.

BTW, why won't this code work in a multi-threaded environment? Is it
because Log4perl is not ready for it or something more insidious? It
seems that some distros are starting to ship Perl with threading
enabled. I'm not sure I'm ready for this brave new world.....

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

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

[William M. <wi...@kn...>]

On Tue, Jan 13, 2004 at 12:53:38AM -0800, Mike Schilli wrote:
> I agree, using the startup handler to call init exactly once is 
> definitely the way to go for now. Hmm ... just had an idea: How about if 
> Log::Log4perl featured an init_once() method, like Apache::DBI, which 
> connects (inits) only if it doesn't have a valid connection 
> (configuration) yet? Or maybe we do Apache::Log::Log4perl :) ?

If you want to take on the task of creating a caching mechanism inside
of log4perl, I'd certainly take advantage of it. I wonder though if
that's the right place for it. Does log4j do this kind of caching? Will
anyone else need this support (I'm guessing so since you seemed to have
been considering it)?

I like the idea of a caching module like Apache::DBI that transparently
provides caching for log4perl objects. I'd be glad to do any testing for
you.

William

-- 
Knowmad Services Inc.
http://www.knowmad.com

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

[William M. <wi...@kn...>]

On Mon, Jan 12, 2004 at 10:05:00PM -0800, Kevin Goess wrote:
> Is this a possibility for you? From 'perldoc mod_perl'
> 
> ~       PerlRequire  perl-scripts/script_to_load_at_startup.pl

Ahh, I didn't think of that one! Good idea. I'll do some more research
and see what I can find out.


> | So far, I have not noticed any problems with
> | repeatedly calling init on each cgi access.
> 
> For myself, I won't say that doing it that way will definitely cause
> problems, but I won't endorse it, either.  I'm going to play it
> conservative and just say, "Your mileage may vary."  Calling init() with
> the same config information isn't the best, performance-wise, and it's
> kind of outside the bounds of our design/conception.  Unless Mike has
> something better to say about it, that is...

Yeah, I can understand the performance hit. I may need to devise a means
of storing the log4perl object into memory and drawing it from there.
That's a bit beyond my current level of mod_perl skills so I'll need to
work on it. I'll try over at the CGI::App list to see if anyone has a
solution.


Regards,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

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

[Mike S. <msc...@ao...>]

Mike Schilli wrote on 1/13/2004, 12:53 AM:

 > Hmm ... just had an idea:

Oh, and for now, something like

     use Log::Log4perl;

     unless($Log::Log4perl::Logger::INITIALIZED) {
         Log::Log4perl->init(...);
     }

might do the trick (at least if it's single-threaded) ...

--
-- Mike
Mike Schilli
m...@pe...

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

[Mike S. <msc...@ao...>]

Kevin Goess wrote on 1/12/2004, 10:05 PM:

 > Calling init() with
 > the same config information isn't the best, performance-wise, and it's
 > kind of outside the bounds of our design/conception.  Unless Mike has
 > something better to say about it, that is...

I agree, using the startup handler to call init exactly once is 
definitely the way to go for now. Hmm ... just had an idea: How about if 
Log::Log4perl featured an init_once() method, like Apache::DBI, which 
connects (inits) only if it doesn't have a valid connection 
(configuration) yet? Or maybe we do Apache::Log::Log4perl :) ?

-- 
-- Mike
Mike Schilli
m...@pe...

Re: [log4perl-devel] Logging via email

[Mike S. <msc...@ao...>]

Stathy G Touloumis wrote on 1/12/2004, 12:59 PM:

 > I can't seem to get Log::Log4perl to work with
 > Log::Dispatch::Email::MailSendmail even though using
 > Log::Dispatch::Email::MailSendmail on the command line works fine.

Just tried it -- works for me. The only thing I changed was that I set 
"buffered" to 0, since the default mode of Email::MailSendmail seems to 
be 1, which causes messages to be buffered and not to be sent out. 
Here's the code:

use Log::Log4perl;

Log::Log4perl::init(\q{
log4perl.logger.mapping = ERROR, Errormapping, Tnotify
log4perl.additivity.mapping = 0

log4perl.appender.Tnotify             = Log::Dispatch::Email::MailSendmail
log4perl.appender.Tnotify.name        = tnotify
log4perl.appender.Tnotify.min_level   = debug
log4perl.appender.Tnotify.from        = fo...@ba...
log4perl.appender.Tnotify.to          = m...@pe...
log4perl.appender.Tnotify.layout      = Log::Log4perl::Layout::SimpleLayout
log4perl.appender.Tnotify.buffered    = 0

log4perl.appender.Errormapping        = Log::Log4perl::Appender::Screen
log4perl.appender.Errormapping.mode      = clobber
log4perl.appender.Errormapping.autoflush = 1
log4perl.appender.Errormapping.filename  = ./error_mapping.txt
log4perl.appender.Errormapping.layout    = 
Log::Log4perl::Layout::PatternLayout
log4perl.appender.Errormapping.layout.ConversionPattern = %m%n%n
});

my $logger = Log::Log4perl::get_logger("mapping");
$logger->error("blah");

__END__

-- 
-- Mike
Mike Schilli
m...@pe...

Re: [log4perl-devel] File Rollover

[Mike S. <msc...@ao...>]

Mark Pfeiffer wrote on 1/11/2004, 2:18 PM:

 > Yes. I havn't done any performance testing to see if it is a major
 > issue. Do you have some view on this? Are there better ways?

One improvement would be being able to disable it if there's just one 
writer thread/process or if synching is done otherwise (e.g. via a l4p 
Synchronized appender).

-- 
-- Mike
Mike Schilli
m...@pe...

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

[Kevin G. <ke...@go...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| are handled with Apache::Registry for performance improvement. I do not
| believe there is any way to have the init function only called once
| within this framework.

Is this a possibility for you? From 'perldoc mod_perl'

~       PerlRequire  perl-scripts/script_to_load_at_startup.pl

~       A PerlRequire file is commonly used for intialization dur­
~       ing server startup time.  A PerlRequire file name can be
~       absolute or relative to ServerRoot or a path in @INC.   A
~       PerlRequire'd file must return a true value, i.e., the end
~       of this file should have a:

~        1; #return true value

~       See eg/startup.pl for an example to start with.


| So far, I have not noticed any problems with
| repeatedly calling init on each cgi access.

For myself, I won't say that doing it that way will definitely cause
problems, but I won't endorse it, either.  I'm going to play it
conservative and just say, "Your mileage may vary."  Calling init() with
the same config information isn't the best, performance-wise, and it's
kind of outside the bounds of our design/conception.  Unless Mike has
something better to say about it, that is...




- --
Happy Trails. . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510)525-5217
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQFAA4qL4g4/Tl71vUkRAnXBAKClBW3VI1c1yWA7O2hF+CI5p/leGQCfXMev
N4Iwt83BXisoqwralJyaPCY=
=6tio
-----END PGP SIGNATURE-----

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

[William M. <wi...@kn...>]

Hi all,

The recent discussions about not repeatedly calling the init (or
easy_init) functions when running in modperl environments bring up an
issue that I had not considered.

I use CGI::Application for web development. It has cgi instance scripts
that invoke modules to allow for modular web applications. These scripts
are handled with Apache::Registry for performance improvement. I do not
believe there is any way to have the init function only called once
within this framework. So far, I have not noticed any problems with
repeatedly calling init on each cgi access.  Are there any other
CGI::App users here who can shed some light on this issue?

Thanks,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

[log4perl-devel] Logging via email

[Stathy G T. <sto...@tu...>]

I can't seem to get Log::Log4perl to work with 
Log::Dispatch::Email::MailSendmail even though using 
Log::Dispatch::Email::MailSendmail on the command line works fine.  Also, 
there are 2 appenders assigned to the category (one file, one email) and 
the file seems to get the messages fine.  Any ideas?

This works :

perl -MLog::Dispatch::Email::MailSendmail -e '$e = 
Log::Dispatch::Email::MailSendmail->new( to=> 
q(sto...@tu...), from=> q(te...@te...), name=> 
q(test), min_level=> q(debug) ); $e->log( message=> q(testttttt), level=> 
q(error) );'

This configuration only logs to the file appender (logging involked using 
error method):

log4perl.logger.mapping = ERROR, Errormapping, Tnotify
log4perl.additivity.mapping = 0

log4perl.appender.Tnotify             = Log::Dispatch::Email::MailSendmail
log4perl.appender.Tnotify.name        = tnotify
log4perl.appender.Tnotify.min_level   = debug
log4perl.appender.Tnotify.from        = te...@te...
log4perl.appender.Tnotify.to          = sto...@tu...
log4perl.appender.Tnotify.layout      = Log::Log4perl::Layout::SimpleLayout

log4perl.appender.Errormapping           = Log::Log4perl::Appender::File
log4perl.appender.Errormapping.mode      = clobber
log4perl.appender.Errormapping.autoflush = 1
log4perl.appender.Errormapping.filename  = ./error_mapping.txt
log4perl.appender.Errormapping.layout    = Log::Log4perl::Layout::PatternLayout
log4perl.appender.Errormapping.layout.ConversionPattern = %m%n%n





Stathy G. Touloumis

Lead Programmer, Benchmarks
Edison Schools, Inc.
Ph: 847.676.6663

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Tony B. <log...@tm...>]

On Sat, Jan 10, 2004 at 01:17:49AM +0000, Tony Bowden wrote:
> Switching my method in new() from
>   Log::Log4perl->easy_init($args->{DEBUG} ? $DEBUG : $ERROR);
> to 
>   get_logger->level($args->{DEBUG} ? $DEBUG : $ERROR);
> seems to do the trick in my simple test. I'll try plugging this approach
> into the real application tomorrow.

Works like a charm.

Thanks all,

Tony

Re: [log4perl-devel] File Rollover

[Mark P. <ma...@ml...>]

On Dec 26, Mike Schilli's good news was:

> Mark Pfeiffer wrote on 12/23/2003, 3:26 PM:
> 
>  > We handle multiple writers using flock().
> 
> Thanks for clarifying that, Mark. It seems like you're synchronizing 
> every logged message via flock(), though (sub logit()) -- is that 
> intended? I would guess this has a major performance impact.
> 
Yes. I havn't done any performance testing to see if it is a major
issue. Do you have some view on this? Are there better ways?

cheers
markpf

Re: [log4perl-devel] Fwd: Changing the loglevel in another package

[Mike S. <msc...@ao...>]

 > I've written a test which succeeds when I call get_logger
 > with "" but fails when I call it using get_logger(). (See
 > below)
 >
 > Are there reasons that just get_logger("") should succeed?

get_logger() is equivalent to get_logger(__PACKAGE__), while 
get_logger("") gets the root logger. I'm gonna update the docs, thanks 
for the test case ...

-- 
-- Mike
Mike Schilli
m...@pe...

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Tony B. <log...@tm...>]

On Fri, Jan 09, 2004 at 10:14:33AM -0800, Mike Schilli wrote:
> init() (or easy_init()) should be called exactly once, when the 
> application starts up. If you're running a typical CGI-Skript, running 
> it per request is fine. However, in a persistent environment (like 
> mod_perl), calling init() (or easy_init()) per request is not 
> recommended ... If you want to reset its level in the new() 
> call, just do something like ... $logger->level($ERROR);

Aha. That makes sense. 

I think this should be made much clearer in the docs. It's quite an
important philosophical point about how the package is used that probably
differs quite significantly from how many people's home-grown approaches
would have worked.

Switching my method in new() from
  Log::Log4perl->easy_init($args->{DEBUG} ? $DEBUG : $ERROR);
to 
  get_logger->level($args->{DEBUG} ? $DEBUG : $ERROR);
seems to do the trick in my simple test. I'll try plugging this approach
into the real application tomorrow.

Thanks,

Tony

[log4perl-devel] Fwd: Changing the loglevel in another package

[Mike S. <msc...@ao...>]

------ Forwarded message ------
From: Roland Bauer <rol...@ff...>
Date: Tue, 6 Jan 2004 23:29:49 +0100 (Westeurop=E4ische Normalzeit)
Subject: Changing the loglevel in another package
To: log...@li...

Hi,

I've written a test which succeeds when I call get_logger
with "" but fails when I call it using get_logger(). (See
below)

Are there reasons that just get_logger("") should succeed?

Regards,
Roland

################################# START #####################

#!/usr/bin/perl

=3Dhead1 DESCRIPTION

This test changes the logging level in another
package.

get_logger() is WRONG, get_logger("") is OK.

Is this a bug or a feature?

=3Dcut

use strict;

use Test::More;
plan tests=3D>2*4;

use Log::Log4perl qw(:easy);

# I have 0.37 installed ...
$Log::Log4perl::VERSION >=3D 0.37 or warn "Wrong version";

Log::Log4perl->easy_init;

my $level;

for my $level ($DEBUG, $INFO, $WARN, $ERROR) {
     Log::Log4perl->get_logger("")->level($level);
     Pack_A::test_1($level);
}

# The level does not change from $ERROR (as set above)

for my $level ($DEBUG, $INFO, $WARN, $ERROR) {
     Log::Log4perl->get_logger()->level($level);
     Pack_A::test_1($level); # shouldn't this succeed?
     #Pack_A::test_1($ERROR); # this succeeds, shall it?
}

package Pack_A;
use Test::More;
use Log::Log4perl qw(:easy);
sub test_1 {
     my ($level) =3D @_;
     ok($level =3D=3D Log::Log4perl->get_logger("")->level);
}
1;

################################# END #############################


--=20
Roland Bauer
http://www.fff.at/contact/



-------- End of message -------

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Mike S. <msc...@ao...>]

Tony Bowden wrote on 1/9/2004, 9:17 AM:

 > Thus, in the application, the init() is called per request, based on the
 > CGI paramaters received.

init() (or easy_init()) should be called exactly once, when the 
application starts up. If you're running a typical CGI-Skript, running 
it per request is fine. However, in a persistent environment (like 
mod_perl), calling init() (or easy_init()) per request is not 
recommended -- what will happen is that the L4p settings for the entire 
system will be clobbered and set to the new configuration. If you have 
test appenders defined and then you're running easy_init(), L4p will 
clobber them and go for the settings defined in easy_init() -- typically 
by writing messages to STDOUT.

In your init() call, you specified just one logger:

     log4perl.category = INFO, BufferApp

That's the root logger. If you want to reset its level in the new() 
call, just do something like

     my $logger = Log::Log4perl::get_logger("");
     $logger->level($ERROR);

BTW, :easy mode automatically defines loggers (so-called stealth 
loggers) named after the current package. So, to get a logger defined by 
:easy in the "main" package, do this:

use Log::Log4perl qw(:easy);

Log::Log4perl->easy_init($DEBUG);
DEBUG("gets logged");
ERROR("gets logged");

my $logger = get_logger("main");
$logger->level($ERROR);

DEBUG("doesn't get logged");
ERROR("gets logged");

-- 
-- Mike
Mike Schilli
m...@pe...

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Tony B. <log...@tm...>]

On Fri, Jan 09, 2004 at 05:17:02PM +0000, Tony Bowden wrote:
> I'm using this in a web environment. By default only things of level
> ERROR get logged. However, requests can supply a parameter, which
> will switch logging to, for example, INFO level.

To clarify, a closer example to what I'm really doing:

-------

package My::Foo;

use Log::Log4perl ':easy';

sub new {
  my $class = shift;
  my $args = shift || {};
  Log::Log4perl->easy_init($args->{DEBUG} ? $DEBUG : $ERROR);
  bless {} => $class;
}

sub do_it { get_logger()->info("do_it called") }

package main;

use Test::More tests => 1;

Log::Log4perl::init(\q{
  screen = Log::Log4perl::Appender::TestBuffer
  log4perl.category = INFO, BufferApp
  log4perl.appender.BufferApp = ${screen}
  log4perl.appender.BufferApp.layout = \
      Log::Log4perl::Layout::PatternLayout
  log4perl.appender.BufferApp.layout.ConversionPattern = %d %F{1} %L> %m %n
});


{
  my $log = Log::Log4perl::Appender::TestBuffer->by_name("BufferApp");
  My::Foo->new()->do_it;
  is $log->buffer, "", "do_it not logged normally";
}

{
  my $log = Log::Log4perl::Appender::TestBuffer->by_name("BufferApp");
  My::Foo->new({ DEBUG => 1 })->do_it;
  like $log->buffer, qr/do_it/, "do_it logged in debug mode";
}


----------

Tony

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Tony B. <log...@tm...>]

On Fri, Jan 09, 2004 at 08:27:05AM -0800, Kevin Goess wrote:
> No doubt.  When you initialize Log4perl it's initialized for the entire
> perl interpreter.  With that in mind you don't need to call init()
> inside your new() method, just put it in the body of the module so that
> it loads once.  Then make sure the test's init() method gets called
> after the module's init method, like it does in your code sample.  See
> the patch below.

I think I'm missing something fairly fundamental then.

I'm using this in a web environment. By default only things of level
ERROR get logged. However, requests can supply a parameter, which
will switch logging to, for example, INFO level.

Thus, in the application, the init() is called per request, based on the
CGI paramaters received.

So, in my test I really need to make the exact same request twice,
except the second time I want to also set that parameter. I then need to
check that there were no messages the first time, and certain ones the
second time.

How can do this?

I suspect there's a philosophical problem approach that I'm not quite
grokking yet, rather than a technical problem.

Tony