Re: [log4perl-devel] logger state is global

[Mike S. <m...@pe...>]

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
m...@pe...