log4perl-devel — Ongoing log4perl development

[log4perl-devel] Log4perl Talk on 9/25 in San Francisco

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

Log4perl enthusiasts,

I'll be giving a presentation on Log4perl at the San Francisco Perl
Mongers on 9/25, stop by if you're in the area:

   http://sf.pm.org/weblog

See you there!

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] requesting feedback on Log::Abstract

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

On Mon, 10 Sep 2007, Jonathan Swartz wrote:

> It isn't different, by itself, but it translates naturally into
>
>      $log->debug("Current arguments: " . Dumper(\@_)) if $log->is_debug;
>
> whereas if you start off in easy mode, you don't have any way to get
> at the logger (as far as I can tell).

get_logger() without arguments defaults to the current package:

   DEBUG "Current arguments: " . Dumper(\@_) if get_logger()->is_debug;

But I agree that that's a stretch. We could export IS_DEBUG(), but it
hasn't come up yet, so I assume people don't stumble over it often.

> > By the way, in Log4perl you can pass a subroutine ref to the method,
> > which eliminates the problem:
> >
> >     DEBUG sub { "Current arguments: " . Dumper(\@_) };
> >
>
> Right, I forgot about the subroutine syntax. I do think that is a
> little harder for novices, and a little more expensive, than the
> conditional (especially when the conditional is against a simple
> scalar).

Interesting. Have you benchmarked it?

> To be honest I have other problems with porting the DEBUG etc
> keywords into a generic, universally acceptable API.
> The all-caps is not in line with Perl standards,

Clearly, you could argue either way. I like it :).

> and it interferes with
> Carp::Assert's DEBUG.

Clearly, an API like this will clash with one module or another.

>It also introduces a second, less-powerful API that isn't trivial to
>convert to the primary API when you need more features. IMHO it is
>better to just provide users with an easy way to create the default
>logger, and then maintain a single powerful OO API. My two cents.

I disagree. Easy things should be easy, hard things possible. Sounds
familiar? :)

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] requesting feedback on Log::Abstract

[Jonathan S. <sw...@po...>]

>> The  problem I have with the DEBUG etc keywords is that they promote
>> inefficient behavior. e.g.
>>
>>      DEBUG "Current arguments: " . Dumper(\@_);
>>
>> will take the performance hit for Dumper() even when debug logging
>> isn't turned on.
>
> Sure, although I don't see how
>
>     $log->debug("Current arguments: " . Dumper(\@_));
>
> is any different.

It isn't different, by itself, but it translates naturally into

     $log->debug("Current arguments: " . Dumper(\@_)) if $log->is_debug;

whereas if you start off in easy mode, you don't have any way to get  
at the logger (as far as I can tell).

> By the way, in Log4perl you can pass a subroutine ref
> to the method, which eliminates the problem:
>
>     DEBUG sub { "Current arguments: " . Dumper(\@_) };
>

Right, I forgot about the subroutine syntax. I do think that is a  
little harder for novices, and a little more expensive, than the  
conditional (especially when the conditional is against a simple  
scalar).

To be honest I have other problems with porting the DEBUG etc  
keywords into a generic, universally acceptable API. The all-caps is  
not in line with Perl standards, and it interferes with  
Carp::Assert's DEBUG. It also introduces a second, less-powerful API  
that isn't trivial to convert to the primary API when you need more  
features. IMHO it is better to just provide users with an easy way to  
create the default logger, and then maintain a single powerful OO  
API. My two cents.

Jon

Re: [log4perl-devel] requesting feedback on Log::Abstract

[Jim C. <jim...@gm...>]

Mike Schilli wrote:
>
> While you're at it, here's my pipe dream: I want something like Dtrace,
> where the logging framework zeroes out the opcodes that are currently
> inactive, and the interpreter rushes through them at light speed with
> practically no overhead.
>
> -- Mike
>   


This sounds like what I did with Log4perl::AutoCategorize,
( which is unsupportable - due to breakage of B::Generate )

FWIW, it hacked the optree to cause an AUTOLOAD fn to instantiate
a different sub for every call-point.  that new sub could be customized
for to the way the config applied to that call-point, thus inlining all
the config decisions.  Assuming B::Generate comes back to life
(there is hope yet), it will be practical to truly no-op the call.
 

Re: [log4perl-devel] requesting feedback on Log::Abstract

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

On Sat, 8 Sep 2007, Jonathan Swartz wrote:

> Did you see this in the posting?
>
>      As a convenient shorthand, you can use
>
>              package Foo;
>              use Log::Abstract qw($log);
>
>      to create the logger, which is equivalent to the first example
> except that $log is
>      (necessarily) a package-scoped rather than lexical variable.
>
> So this creates a logger for you with the category set to the current
> package, similar to easy mode. The syntax is pretty minimal.

Ah, gotcha. So you would call

    $log->debug(...)

instead of

    DEBUG "..."

which is probably acceptable in terms of additional key strokes
(although it might throw off novices).

> The  problem I have with the DEBUG etc keywords is that they promote
>inefficient behavior. e.g.
>
>      DEBUG "Current arguments: " . Dumper(\@_);
>
> will take the performance hit for Dumper() even when debug logging
> isn't turned on.

Sure, although I don't see how

    $log->debug("Current arguments: " . Dumper(\@_));

is any different. By the way, in Log4perl you can pass a subroutine ref
to the method, which eliminates the problem:

    DEBUG sub { "Current arguments: " . Dumper(\@_) };

Efficient, but ugly :).

While you're at it, here's my pipe dream: I want something like Dtrace,
where the logging framework zeroes out the opcodes that are currently
inactive, and the interpreter rushes through them at light speed with
practically no overhead.

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] requesting feedback on Log::Abstract

[Jonathan S. <sw...@po...>]

 >
 > On Sep 8, 2007, at 1:19 PM, Mike Schilli wrote:
 >
 > > On Fri, 7 Sep 2007, Jonathan Swartz wrote:
 > >
 > > I'd be interested in feedback on a proposed module, Log::Abstract,
 > > described here:
 > >
 > >      http://use.perl.org/~jonswar/journal/34366
 >
 > ...
 >
 > By the way, I don't agree that "For small modules that want to
 > minimize dependencies, depending on Log4perl (for example) is a
 > non-starter." The Log4perl core doesn't have dependencies other
 > than perl's core modules.

Fair enough.

 >
 > One thing missing from your proposal is Log4perl's :easy mode
 > [sourceforge.net]. If you think about it, getting a logger and
 > calling its method is a lot of typing, given that you just want
 > to log something. That's why in Log4perl you can use
 >
 > DEBUG "Log this!";
 >
 > and you're done. No getting a logger, no method calling, no
 > category passing. It's all automatic. Behind the scenes, it gets
 > a 'stealth logger' with the category set to the current package
 > and calls the appropriate logging method on it. This feature is
 > huge. I'm using it almost exclusively in everything I write.
 >
 > Any chance of adding that?

Did you see this in the posting?

     As a convenient shorthand, you can use

             package Foo;
             use Log::Abstract qw($log);

     to create the logger, which is equivalent to the first example  
except that $log is
     (necessarily) a package-scoped rather than lexical variable.

So this creates a logger for you with the category set to the current  
package, similar to easy mode. The syntax is pretty minimal. The  
problem I have with the DEBUG etc keywords is that they promote  
inefficient behavior. e.g.

     DEBUG "Current arguments: " . Dumper(\@_);

will take the performance hit for Dumper() even when debug logging  
isn't turned on. This may be fine for a particular application where  
performance is not an issue, but I would never want to encourage any  
CPAN module author to do this.

In fact, in this thread on perl.module-authors,

     http://groups.google.com/group/perl.module-authors/msg/ 
cbd5a168d5d780a8?hl=en&

it was suggested that even the usual "fast" $log->is_debug() check is  
too much of a hit. So I proposed we export a live $log_is_debug  
variable that would change dynamically to reflect the current level.

I suppose one could combine the syntaxes:

     DEBUG "Current arguments: " . Dumper(\@_) if $log_is_debug;

but at this point you are only saving 6 characters or so.

 >
 > One thing to watch out for is performance. People don't want
 > their applications to slow down just because a module has a
 > logging capability.

Exactly my point above. :)

Thanks for your positive feedback! I will definitely need to have the  
support of major logging frameworks such as log4perl for this module  
to be a success.

Best,
Jon

Re: [log4perl-devel] requesting feedback on Log::Abstract

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

On Fri, 7 Sep 2007, Jonathan Swartz wrote:

> I'd be interested in feedback on a proposed module, Log::Abstract,
> described here:
>
>      http://use.perl.org/~jonswar/journal/34366
>
> This would be a tiny module designed to bridge CPAN modules that wish
> to log (e.g. LWP, DBI, ...) with existing logging frameworks (e.g.
> Log4perl), without the need for those modules to explicitly tie
> themselves to a single framework.
>
> I'm a longtime log4perl fan/user, and Log::Abstract is my way of
> increasing the input to log4perl in applications without resorting to
> tricks such as infiltrate_lwp(). :)

Hi Jonathan,

you're addressing something really important here. It is really
unfortunate that important CPAN modules like LWP or Rose::DB don't have
usable logging mechanisms in place. Once you're used to category-based
logging it's hard to go back to these home-grown and less convenient
solutions.

I think it's a great idea to promote standardized logging on CPAN and
letting the user choose the actual implementation will definitely help
to make strides towards that goal.

By the way, I don't agree that "For small modules that want to minimize
dependencies, depending on Log4perl (for example) is a non-starter." The
Log4perl core doesn't have dependencies other than perl's core modules.

One thing missing from your proposal is Log4perl's :easy mode. If you
think about it, getting a logger and calling its method is a lot of
typing, given that you just want to log something. That's why in
Log4perl you can use

    DEBUG "Log this!";

and you're done. No getting a logger, no method calling, no category
passing. It's all automatic. Behind the scenes, it gets a 'stealth
logger' with the category set to the current package and calls the
appropriate logging method on it. This feature is huge. I'm using it
almost exclusively in everything I write. Any chance of adding that?

Keep up the great work!

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] requesting feedback on Log::Abstract

[Jonathan S. <sw...@po...>]

Hello,

I'd be interested in feedback on a proposed module, Log::Abstract,  
described here:

     http://use.perl.org/~jonswar/journal/34366

This would be a tiny module designed to bridge CPAN modules that wish  
to log (e.g. LWP, DBI, ...) with existing logging frameworks (e.g.  
Log4perl), without the need for those modules to explicitly tie  
themselves to a single framework.

I'm a longtime log4perl fan/user, and Log::Abstract is my way of  
increasing the input to log4perl in applications without resorting to  
tricks such as infiltrate_lwp(). :)

Feedback most welcome, either here or on the use.perl forum.

Thanks!
Jon

Re: [log4perl-devel] Looking for function to explicitly reload config file

[Joachim S. <js...@ac...>]

>>>>> "KMG" == Kevin M Goess <cp...@go...> writes:

Kevin,

>> I'd like to use a
>> function or method from Log::Log4perl to explicitly reload the
>> log4perl config file. How do I do that? Do I call init() again?

KMG> Yeah, go ahead and call Log::Log4Perl->init all day.  You'll get the
KMG> same functionality that init_and_watch does when it reloads a changed
KMG> config.

Thanks a lot for the very quick and concise answer, right on spot.
You're awesome, guys!

	Joachim

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod				Email: js...@ac...
Roedermark, Germany

Re: [log4perl-devel] Looking for function to explicitly reload config file

[Kevin M. G. <cp...@go...>]

Joachim,

> Great piece of work, your Log::Log4perl module. Especially in mixed
> Java/Perl environments, it makes log management a breeze. :-)

Thanks!

> I'd like to use a
> function or method from Log::Log4perl to explicitly reload the
> log4perl config file. How do I do that? Do I call init() again?

Yeah, go ahead and call Log::Log4Perl->init all day.  You'll get the
same functionality that init_and_watch does when it reloads a changed
config.

> can I continue to use previously attained logger objects or do I
> need to call get_logger() anew?

Yes, all your $logger objects are still good (assuming you haven't
un-supported them in your new config).  The existing singleton objects
stay the same, but the coderefs they contain have been updated with the
new behavior.

[log4perl-devel] Looking for function to explicitly reload config file

[Joachim S. <js...@ac...>]

Hi,

Great piece of work, your Log::Log4perl module. Especially in mixed 
Java/Perl environments, it makes log management a breeze. :-)

But now I stumbled over something that I could not locate in the 
documentation or the FAQ. (Looking at the source of 
init_and_watch() didn't help either. :-() I'd like to use a 
function or method from Log::Log4perl to explicitly reload the 
log4perl config file. How do I do that? Do I call init() again?

If calling init() is the right solution, does this change the 
existing singleton object or does this allocate a new one? I.e., 
can I continue to use previously attained logger objects or do I 
need to call get_logger() anew?

This is for a daemon that receives commands to reconfigure itself 
on a TCP command channel. I don't want to use init_and_watch() for 
performance reasons, and reload-by-signal is a no-no as well. (All 
signals are handled by the daemon, a subsidiary module like 
Log::Log4perl must not install an own signal handler.)

Any tips or hints would be appreciated.

Best,
	Joachim

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod				Email: js...@ac...
Roedermark, Germany

[log4perl-devel] DBI Appender user suggestion and silent failure issue for mismatched placeholder count

[Adrian C. <ad...@yo...>]

I'm using Log::Log4perl::Appender::DBI and I have a few end-user 
suggestions to make.

I have a significant slab of existing Log::Log4perl code which uses 
variable number of arguments like this:

   Log::Log4perl -> get_logger() -> debug("Parsing start"):
   ...
   Log::Log4perl -> get_logger() -> debug("Done, ", $error_count, " 
errors.");

Using this sort of code with Log::Log4perl::Appender::DBI the way it's 
currently suggested/recommended by the perldoc (prepared statements, '?' 
placeholders and warp_message=0) is presently a poor experience, because 
the number of placeholders is variable.  At the moment this means most 
of my DBI inserts were failing silently and I had to uncomment the 
"warn" on line 138 of Log::Log4perl::Appender::DBI to find out what was 
going wrong (which is rather unfortunate.)

I think it would be better to do something like this as a default in the 
perldoc example (ie. without warp_message, and %m explicitly specified 
as a parameter)

  log4perl.appender.DBLog = Log::Log4perl::Appender::DBI
  log4perl.appender.DBLog.datasource = DBI:mysql:database=log;host=localhost
  log4perl.appender.DBLog.username = user
  log4perl.appender.DBLog.password = pass
  log4perl.appender.DBLog.sql = insert into cc3 (timestamp, severity, 
source, source_line, host, caller, file, message) values 
(unix_timestamp(), ?, ?, ?, ?, ?, ?, ?);
  log4perl.appender.DBLog.params.1 = %p
  log4perl.appender.DBLog.params.2 = %X{source}
  log4perl.appender.DBLog.params.3 = %X{source-line}
  log4perl.appender.DBLog.params.4 = %H
  log4perl.appender.DBLog.params.5 = %M
  log4perl.appender.DBLog.params.6 = +%L %F
  log4perl.appender.DBLog.params.7 = %m
  log4perl.appender.DBLog.usePreparedStmt = 1
  log4perl.appender.DBLog.layout = Log::Log4perl::Layout::NoopLayout

The existing example could then be included in the perldoc under a 
section entitled ("How to get access to individual arguments to debug(), 
warn() etc.")

But it's a great class nevertheless :)

Thanks,
A.

-- 
Adrian Corston
Support Engineer
YourAmigo

IMPORTANT - This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information in which case neither is intended to be waived. YourAmigo retains ownership of all copyright, trade secrets and other intellectual property rights in the email and attachments. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify us and remove it from your system. It is your responsibility to check any attachments for viruses and defects before opening or sending them on. YourAmigo collects personal information to provide and market our services. For more information about use, disclosure and access, see our privacy policy at http://www.youramigo.com

[log4perl-devel] Minor bug with usePreparedStmt and buggerSize in Log::Log4perl::Appender::DBI

[Adrian C. <ad...@yo...>]

Log::Log4perl::Appender::DBI line 44:
    $self->{BUFFERSIZE} = $p{bufferSize} || 1;

Log::Log4perl::Appender::DBI line 56:
    if ($self->{usePreparedStmt} &&  $self->{bufferSize}){

I think you probably want line 56 to read as follows:
    if ($self->{usePreparedStmt} &&  $self->{BUFFERSIZE}){

Cheers,
A.

-- 
Adrian Corston
Support Engineer
YourAmigo

IMPORTANT - This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information in which case neither is intended to be waived. YourAmigo retains ownership of all copyright, trade secrets and other intellectual property rights in the email and attachments. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify us and remove it from your system. It is your responsibility to check any attachments for viruses and defects before opening or sending them on. YourAmigo collects personal information to provide and market our services. For more information about use, disclosure and access, see our privacy policy at http://www.youramigo.com

Re: [log4perl-devel] Wrapper class question

[Robert H. <si...@gm...>]

Mike Schilli wrote:
> On Tue, 21 Aug 2007, Robert Hicks wrote:
> 
>> sub get_logger { my $class = shift; my $module_name = shift;
>>
>>      unless( Log::Log4perl->initialized ) {
>>
>>          # watch the config file for changes (in seconds)
>>          Log::Log4perl->init_and_watch( "log4perl.conf", 60 );
>>          $Log::Log4perl::caller_depth = 1;
>>      }
>>
>>      return Log::Log4perl->get_logger( $module_name );
>> }
> 
> You're increasing the caller_depth, although you're calling the log
> method in the main program, not in the wrapper. Kick out that line and
> you'll be ok.
> 

Ah! I was just reading up on caller_depth and that part was confusing me.

Robert

Re: [log4perl-devel] Wrapper class question

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

On Tue, 21 Aug 2007, Robert Hicks wrote:

> sub get_logger { my $class = shift; my $module_name = shift;
>
>      unless( Log::Log4perl->initialized ) {
>
>          # watch the config file for changes (in seconds)
>          Log::Log4perl->init_and_watch( "log4perl.conf", 60 );
>          $Log::Log4perl::caller_depth = 1;
>      }
>
>      return Log::Log4perl->get_logger( $module_name );
> }

You're increasing the caller_depth, although you're calling the log
method in the main program, not in the wrapper. Kick out that line and
you'll be ok.

-- Mike

Mike Schilli
m...@pe...

>
> I am not calling it from a module but a "test.pl" file. It logs but I get:
>
> [2007/08/21 12:39:21] [WARN] [[undef] line [undef]] This should go to
> SCREEN and AMG.LOG
>
> How do I change my wrapper to play nicely with Log4perl?
>
> I am emailing here even though it says "devel" in the title since I
> don't see a "users" anywhere.  : )
>
> Bob
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

[log4perl-devel] Wrapper class question

[Robert H. <si...@gm...>]

Cees posted this on Perlmonks and it "works" but I get [undef] for 
filename and line.

sub get_logger {
     my $class = shift;
     my $module_name = shift;

     unless( Log::Log4perl->initialized ) {

         # watch the config file for changes (in seconds)
         Log::Log4perl->init_and_watch( "log4perl.conf", 60 );
         $Log::Log4perl::caller_depth = 1;
     }

     return Log::Log4perl->get_logger( $module_name );
}

I am not calling it from a module but a "test.pl" file. It logs but I get:

[2007/08/21 12:39:21] [WARN] [[undef] line [undef]] This should go to 
SCREEN and AMG.LOG

How do I change my wrapper to play nicely with Log4perl?

I am emailing here even though it says "devel" in the title since I 
don't see a "users" anywhere.  : )

Bob

Re: [log4perl-devel] Log4perl Categories

[Lee G. <LGo...@UK...>]

Thanks, Eric - that made sense, and the config is as I imagined.

I'm really into the ':easy' way, though, despite the OO nature of most =
of my modules, so I'll have to start sub-classing, I think.

Thanks again
Lee

________________________________________
From: Berg, Eric [mailto:eri...@le...]=20
Sent: 16 August 2007 16:49
To: Lee Goddard; log...@li...
Subject: RE: [log4perl-devel] Log4perl Categories

Lee,
=A0
I use a custom logging class that exports a get_logger($category) that =
automatically prepends the namespace hierarchy to the category passed =
in, so that I can always do this:
=A0
My logger config file looks kinda like this:
=A0
log4perl.logger.MyMods.Action.kgc_dir=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D =
DEBUG, DebugLog
log4perl.logger.MyMods.Action.param=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D =
TRACE, DebugLog
log4perl.logger.MyMods.Action.rebless=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=3D =
TRACE, DebugLog
log4perl.logger.MyMods.ActionRunner.get_status =3D DEBUG, DebugLog
log4perl.logger.MyMods.ActionRunner.get_status_from_file =3D TRACE, =
DebugLog
log4perl.logger.MyMods.ActionRunner.run=A0=A0=A0=A0=A0=A0=A0 =3D DEBUG, =
DebugLog
log4perl.logger.MyMods.ActionRunner.status_file_name =3D TRACE, DebugLog
log4perl.logger.MyMods.Runner.Diff.run=A0=A0=A0=A0=A0=A0=A0=A0=A0=3D =
TRACE, DebugLog
log4perl.logger.MyMods.Runner.Diff.get_reference_action =3D DEBUG, =
DebugLog
log4perl.logger.MyMods.Runner.Dummy.run=A0=A0=A0=A0=A0=A0=A0 =3D DEBUG, =
DebugLog
log4perl.logger.MyMods.Test.get_runner=A0=A0=A0=A0=A0=A0=A0=A0 =3D =
TRACE, DebugLog
=A0
Where each of the last items in the category (i.e., kgc_dir, param, =
rebless, etc.) are method names in my modules.
=A0
In each module I just do this:
=A0
sub my_method {
=A0=A0=A0 my $self =3D shift;
=A0=A0=A0 my $log =3D get_logger('my_method');
=A0
...
=A0
}
=A0
My get_logger looks like this:
=A0
sub get_logger {
=A0=A0=A0 my $category =3D shift;
=A0=A0=A0 my ( $logger, $log_focus, @log_focus );
=A0
=A0=A0=A0 # Initialize if we're not so already
=A0=A0=A0 init() unless Log::Log4perl->initialized();
=A0
=A0=A0=A0 # get the caller that we want.
=A0=A0=A0 my ( $package, $filename, $line, $subroutine, $hasargs, =
$wantarray, $evaltext, $is_require, $hints, $bitmask ) =3D caller(0);
=A0
=A0=A0=A0 # Put split package name into=A0 @log_focus
=A0=A0=A0 @log_focus =3D split( '::', $package ) if $package;
=A0
=A0=A0=A0 # If there's a category submitted to this sub, append it to
=A0=A0=A0 if ($category) {
=A0=A0=A0=A0=A0=A0=A0 push( @log_focus, $category );
=A0=A0=A0 }
=A0
=A0=A0=A0 $log_focus =3D join( '.', @log_focus );
=A0
=A0=A0=A0 $logger =3D Log::Log4perl::get_logger($log_focus);
=A0=A0=A0 return $logger;
}
=A0
There's a bit more to it, but this is the essence.
=A0
-ERic.

________________________________________
From: log...@li... =
[mailto:log...@li...] On Behalf Of Lee =
Goddard
Sent: Thursday, August 16, 2007 4:21 AM
To: log...@li...
Subject: [log4perl-devel] Log4perl Categories
Sometimes I need to just see the logging from a specific =
method/subroutine/function.

I realize I can change the log levels within that block of code, but it =
would be convenient to be able to say log4perl.category.bar.twix.eat to =
just see the logging from Bar::Twix's 'eat' method.=A0 Would it be a bad =
idea to incorporate this?

Thanks
Lee

Re: [log4perl-devel] Log4perl Categories

[Lee G. <LGo...@UK...>]

From: Mike Schilli [mailto:m...@pe...]
> On Thu, 16 Aug 2007, Lee Goddard wrote:
>=20
> > Sometimes I need to just see the logging from a specific
> > method/subroutine/function.
> >
> > I realize I can change the log levels within that block of code, but
> > it would be convenient to be able to say
> > log4perl.category.bar.twix.eat to just see the logging from
> > Bar::Twix's 'eat' method.  Would it be a bad idea to incorporate
this?
>=20
> Does this third-party CPAN module solve the problem?
>=20
>     http://search.cpan.org/dist/Log-Log4perl-AutoCategorize/

It may well do, thanks Mike: I'll try it.=20

Does look a little heavy, though, but I will wait to see if I need this
functionality again before sub-classing L4p or supply patches that maybe
nobody else will ever need!

Cheers
Lee

Re: [log4perl-devel] Log4perl Categories

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

On Thu, 16 Aug 2007, Lee Goddard wrote:

> Sometimes I need to just see the logging from a specific
> method/subroutine/function.
>
> I realize I can change the log levels within that block of code, but
> it would be convenient to be able to say
> log4perl.category.bar.twix.eat to just see the logging from
> Bar::Twix's 'eat' method.  Would it be a bad idea to incorporate this?

Does this third-party CPAN module solve the problem?

    http://search.cpan.org/dist/Log-Log4perl-AutoCategorize/

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] Log4perl Categories

[Berg, E. <eri...@le...>]

Lee,
=20
I use a custom logging class that exports a get_logger(=24category) that
automatically prepends the namespace hierarchy to the category passed
in, so that I can always do this:
=20
My logger config file looks kinda like this:
=20
log4perl.logger.MyMods.Action.kgc_dir          =3D DEBUG, DebugLog
log4perl.logger.MyMods.Action.param            =3D TRACE, DebugLog
log4perl.logger.MyMods.Action.rebless          =3D TRACE, DebugLog
log4perl.logger.MyMods.ActionRunner.get_status =3D DEBUG, DebugLog
log4perl.logger.MyMods.ActionRunner.get_status_from_file =3D TRACE,
DebugLog
log4perl.logger.MyMods.ActionRunner.run        =3D DEBUG, DebugLog
log4perl.logger.MyMods.ActionRunner.status_file_name =3D TRACE, DebugLog
log4perl.logger.MyMods.Runner.Diff.run         =3D TRACE, DebugLog
log4perl.logger.MyMods.Runner.Diff.get_reference_action =3D DEBUG,
DebugLog
log4perl.logger.MyMods.Runner.Dummy.run        =3D DEBUG, DebugLog
log4perl.logger.MyMods.Test.get_runner         =3D TRACE, DebugLog
=20
Where each of the last items in the category (i.e., kgc_dir, param,
rebless, etc.) are method names in my modules.
=20
In each module I just do this:
=20
sub my_method =7B
    my =24self =3D shift;
    my =24log =3D get_logger('my_method');
=20
=2E..
=20
=7D
=20
My get_logger looks like this:
=20
sub get_logger =7B
    my =24category =3D shift;
    my ( =24logger, =24log_focus, =40log_focus );
=20
    =23 Initialize if we're not so already
    init() unless Log::Log4perl->initialized();
=20
    =23 get the caller that we want.
    my ( =24package, =24filename, =24line, =24subroutine, =24hasargs, =
=24wantarray,
=24evaltext, =24is_require, =24hints, =24bitmask ) =3D caller(0);
=20
    =23 Put split package name into  =40log_focus
    =40log_focus =3D split( '::', =24package ) if =24package;
=20
    =23 If there's a category submitted to this sub, append it to
    if (=24category) =7B
        push( =40log_focus, =24category );
    =7D
=20
    =24log_focus =3D join( '.', =40log_focus );
=20
    =24logger =3D Log::Log4perl::get_logger(=24log_focus);
    return =24logger;
=7D
=20
There's a bit more to it, but this is the essence.
=20
-ERic.

________________________________

From: log4perl-devel-bounces=40lists.sourceforge.net
=5Bmailto:log4perl-devel-bounces=40lists.sourceforge.net=5D On Behalf Of Lee
Goddard
Sent: Thursday, August 16, 2007 4:21 AM
To: log4perl-devel=40lists.sourceforge.net
Subject: =5Blog4perl-devel=5D Log4perl Categories



Sometimes I need to just see the logging from a specific
method/subroutine/function.

=20

I realize I can change the log levels within that block of code, but it
would be convenient to be able to say log4perl.category.bar.twix.eat to
just see the logging from Bar::Twix's 'eat' method.  Would it be a bad
idea to incorporate this?

=20

Thanks

Lee

=20

Lee Goddard

Senior Software Developer

Advertising.com, London

=20

P Think of the environment before you print this email

=20

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - -

This message is intended only for the personal and confidential use of the =
designated recipient(s) named above.  If you are not the intended =
recipient of this message you are hereby notified that any review, =
dissemination, distribution or copying of this message is strictly =
prohibited.  This communication is for information purposes only and =
should not be regarded as an offer to sell or as a solicitation of an =
offer to buy any financial product, an official confirmation of any =
transaction, or as an official statement of Lehman Brothers.  Email =
transmission cannot be guaranteed to be secure or error-free.  Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such.  All information is subject to change =
without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written =
to be used and cannot be used for the purpose of (i) avoiding U.S. tax =
related penalties or (ii) promoting, marketing or recommending to another =
party any transaction or matter addressed herein.

[log4perl-devel] Log4perl Categories

[Lee G. <LGo...@UK...>]

Sometimes I need to just see the logging from a specific
method/subroutine/function.

=20

I realize I can change the log levels within that block of code, but it
would be convenient to be able to say log4perl.category.bar.twix.eat to
just see the logging from Bar::Twix's 'eat' method.  Would it be a bad
idea to incorporate this?

=20

Thanks

Lee

=20

Lee Goddard

Senior Software Developer

Advertising.com, London

=20

P Think of the environment before you print this email

=20

Re: [log4perl-devel] Questions on Log4perl

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

On Thu, 9 Aug 2007 joe...@jp... wrote:

> I'm working on a script I'd like to use Log4perl on for gathering
> information: STDERR, STDOUT, etc...  I read your 4 page article on
> www.perl.com and it looks like my script is a good candidate for using
> config files.  I don't have a lot of experience using config files in
> my Perl programming and was wondering if you could have non- static
> info in a log4perl config file?

There's two kinds of dynamic values: Dynamic at init() time and dynamic
at log time.

Using dynamic values at init() time is explained here:

    http://log4perl.sourceforge.net/d/Log/Log4perl/FAQ.html#02bbc

And here's how to use dynamic values at log time:

    http://log4perl.sourceforge.net/d/Log/Log4perl/Layout/PatternLayout.html#9af52

Hope that helps!

-- Mike

Mike Schilli
m...@pe...

>  log4perl.PatternLayout.cspec.D = Log4perl::get_pid( sub {use
>  File::Basename; return basename($0) );
>
> Please have patience, I'm trying...
>
> Much thanks for any help,
> Joe McTigue
> joe...@jp...
>
>
>
> -----------------------------------------
> This communication is for informational purposes only. It is not
> intended as an offer or solicitation for the purchase or sale of
> any financial instrument or as an official confirmation of any
> transaction. All market prices, data and other information are not
> warranted as to completeness or accuracy and are subject to change
> without notice. Any comments or statements made herein do not
> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
> and affiliates.
>
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure
> under applicable law. If you are not the intended recipient, you
> are hereby notified that any disclosure, copying, distribution, or
> use of the information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED. Although this transmission and any
> attachments are believed to be free of any virus or other defect
> that might affect any computer system into which it is received and
> opened, it is the responsibility of the recipient to ensure that it
> is virus free and no responsibility is accepted by JPMorgan Chase &
> Co., its subsidiaries and affiliates, as applicable, for any loss
> or damage arising in any way from its use. If you received this
> transmission in error, please immediately contact the sender and
> destroy the material in its entirety, whether in electronic or hard
> copy format. Thank you.
>
> Please refer to http://www.jpmorgan.com/pages/disclosures for
> disclosures relating to UK legal entities.

[log4perl-devel] Questions on Log4perl

[<joe...@jp...>]

Good Morning,

I'm working on a script I'd like to use Log4perl on for gathering 
information: STDERR, STDOUT, etc...
I read your 4 page article on www.perl.com and it looks like my script is 
a good candidate for using
config files.  I don't have a lot of experience using config files in my 
Perl programming and was wondering
if you could have non- static info in a log4perl config file?

Like so,

 log4perl.PatternLayout.cspec.D = Log4perl::get_pid( sub {use 
File::Basename; return basename($0) );

Please have patience, I'm trying...

Much thanks for any help,
Joe McTigue
joe...@jp...
 


-----------------------------------------
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.

Re: [log4perl-devel] Log4Perl Segmentation Faults with Apache1/mod_perl

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

On Tue, 7 Aug 2007, H. Meyer wrote:

> We've been able to "fix" the issue for our local setup.  The following
> appender caused the segfaults:
>
> log4perl.appender.STDERR=Log::Dispatch::Screen
> log4perl.appender.STDERR.stderr=1
> log4perl.appender.STDERR.layout=Log::Log4perl::Layout::PatternLayout
> log4perl.appender.STDERR.layout.ConversionPattern=%d %-5p %5P %6X{uid}
> %c:%M{1}:%L - %m%n

Nothing wrong with this appender. Just for kicks you might want to try
the screen appender that comes with Log4perl,
Log::Log4perl::Appender::Screen, but it shouldn't make a difference. It
supports the same parameters.

Are you using any other libraries with Apache? It is very common that
one bad library causes problems leading to crashes in another, innocent,
library (mod_perl in your case).

 -- Mike

Mike Schilli
m...@pe...

> Corresponding apache error log entries:
>
> DIED: Can't locate object method "DESTROY" via package
> "Log::Dispatch::Screen" at
> /usr/local/share/perl/5.8.8/Log/Log4perl/Logger.pm line 73.
> [Mon Aug  6 11:29:18 2007] [notice] child pid 21957 exit signal
> Segmentation fault (11)
>
> Once that appender is disabled, everything (we currently only use
> Log::Dispatch::File) works without problems.
>
> Greetings
> H. Meyer
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

Re: [log4perl-devel] Log4Perl Segmentation Faults with Apache1/mod_perl

[H. M. <log...@sb...>]

Mike Schilli wrote:
> On Mon, 6 Aug 2007, H. Meyer wrote:
>> I've just encountered very frequent segmentation faults when trying to
>> use Log4Perl in a perl web application running inside of apache 1.3.37
>> and mod_perl 1.29. I am using perl 5.8.8 and the latest Log4Perl
>> version from CPAN.
> 
> Core dumps are unrelated to CPAN modules using plain Perl like Log4perl.
> 
> If a core dump happens, the Perl interpreter perl crashes, which it
> shouldn't do if plain Perl is used (and not compiled .xs code).

We've been able to "fix" the issue for our local setup.
The following appender caused the segfaults:

log4perl.appender.STDERR=Log::Dispatch::Screen
log4perl.appender.STDERR.stderr=1
log4perl.appender.STDERR.layout=Log::Log4perl::Layout::PatternLayout
log4perl.appender.STDERR.layout.ConversionPattern=%d %-5p %5P %6X{uid}
%c:%M{1}:%L - %m%n

Corresponding apache error log entries:

DIED: Can't locate object method "DESTROY" via package
"Log::Dispatch::Screen" at
/usr/local/share/perl/5.8.8/Log/Log4perl/Logger.pm line 73.
[Mon Aug  6 11:29:18 2007] [notice] child pid 21957 exit signal
Segmentation fault (11)

Once that appender is disabled, everything (we currently only use
Log::Dispatch::File) works without problems.

Greetings
H. Meyer