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...@perlmeister.com ------------------------------------------------------------------------------ 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 log4perl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/log4perl-devel
