Re: [log4perl-devel] logger state is global
On Thu, 18 Nov 2010, Tom Metro wrote: > It came about because the $logger object doesn't actually convey the > full state, so when serialized and passed to a remote method, the > remote logging reverts to default logging settings. Yeah, the way it's currently implemented, a logger is only meaningful within an initialized Log4perl-system, there's some system-global magic involved, and you cannot serialize a logger and plant it into another Log4perl-enabled system at runtime easily (yet). Can you explain more about what the use case is for serializing loggers and passing them to remote systems? What properties of the logger might be of interest to the remote system? Is the remote system running Log4perl with exactly the same appenders or different ones? > (On a side note, I had to rewrite easy_init() in order to make it > subclass friendly. We can discuss that further in a separate thread, > if interested.) Sure. > I assume that this practice of maintaining global state in Log4perl > came about because it is convenient to be able to call get_logger() as > a class method, rather than having the application pass an object > around. But it seems that it would be way better if Log4perl was > internally designed to store all state in instance variables, and > leave it to the application developer to decide whether they want to > pass around objects, or dedicate a global variable to it. Agreed. > When I fixed the library code to use > Log::Log4perl->get_logger($class), my first attempt was actually to > pass a logger object to the library, and call > $logger->get_logger($class), assuming get_logger($class) would clone > $logger, set the category, and return a new logger. Instead it fails > in Log::Log4perl->_new() when it tries to bless the already blessed > object. Yes, get_logger() is a class method, calling it by an object is not defined. We should have a better error message, though. > Ultimately I want a method I can call from my libraries where I can > pass in a $logger parameter. The method then looks to see if $logger > is set to anything, and if it is, clones it, sets the category, and > returns the object. Hmm, that's similar to how the class method is defined. If the logger for the category exists, you get a copy, if it isn't, you get a new instance. We could implement an object method that does what you've suggested, can you post some code to display how your class hierarchy looks like and how you call the metods of the derived class from your application? -- Mike Mike Schilli [email protected] -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ log4perl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] warning on uninitialized value when logging undef
On Tue, 23 Nov 2010, Kevin Goess wrote: > Any opinion on this? Or should we stay with the uninitialized > warning, however unhelpful it is? I'm in favor of getting a warning in this case, at least with 'use warnings' mode. It's similar to use warnings; print "The value is $value.\n"; where I would expect a warning if $value was undefined. The warning should point me to the location of the actual INFO call and not to somewhere within the guts of Log4perl, though ... :) -- Mike Mike Schilli [email protected] > This is kind of annoying thing that I noticed recently, if you do > $logger->info($msg) and $msg is undefined then you get a warning: > > perl -W -Ilib -e 'use Log::Log4perl qw(:easy); > Log::Log4perl->easy_init($INFO); INFO(undef)' > Use of uninitialized value in join or string at lib/Log/Log4perl/Appender.pm > line 167. > > and it's not even a very helpful warning since it's buried in the guts of > Log4perl. > > Using git bisect (neat tool) I found while I (myself even!) had fixed the > issue back in > 029d7df8 in 2002, I broke it (me again!) in afb95ef7e in 2003. > > Anyway, this would be the correct fix for it now, if all we're going to do is > make a > string out of it, it's ok just to use the defined bits of the mssage. > ... > > diff --git a/lib/Log/Log4perl/Appender.pm b/lib/Log/Log4perl/Appender.pm > index 923836f..455fd09 100644 > --- a/lib/Log/Log4perl/Appender.pm > +++ b/lib/Log/Log4perl/Appender.pm > @@ -162,10 +162,13 @@ sub log { > #not defined, the normal case > if (! defined $self->{warp_message} ){ > #join any message elements > -$p->{message} = > -join($Log::Log4perl::JOIN_MSG_ARRAY_CHAR, > - @{$p->{message}} > - ) if ref $p->{message} eq "ARRAY"; > +if (ref $p->{message} eq "ARRAY"){ > + $p->{message} = > +join($Log::Log4perl::JOIN_MSG_ARRAY_CHAR, > +grep { defined $_ } > +@{$p->{message}} > +); > +} > > #defined but false, e.g. Appender::DBI > } elsif (! $self->{warp_message}) { > > > If nobody objects I can make a unit test for it as well and push it to Mike > via github. > > > > -- > Kevin G. > > -- > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > ___ > log4perl-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/log4perl-devel > -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ log4perl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/log4perl-devel
