log4perl-devel — Ongoing log4perl development

Re: [log4perl-devel] Problems with uninitialized root-logger in log::log4perl

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

On Tue, 4 Dec 2007, Johannes Kilian wrote:

> No - no __DIE__ handler within my own perl-modules/perl files. Perhaps
> there might be some troublesome __DIE__ handler within the officiall
> perl modules (installed in Perl\lib or Perl\site\lib) - But how can
> I find out which one is it?

Trace it:

    PERLDB_OPTS="NonStop=1 AutoTrace=1 frame=2" perl -dS program

> >> 4.) Finishing my program an error from log4perl occurs:     (in cleanup) Internal error: Root Logger not initialized. at C:/Programme/Perl/site/lib/Log/Log4perl/Logger.pm line 557 during global destruction.
> >>
>
> How can I avoid the internal error above?
> Perhaps the uninitialized root logger causes the erroneous exception
> handling as described in point 3.)?

I'm not sure how you get there - is there an easy way for me to
reproduce this problem?

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] Log::Log4Perl::Util::module_available broken...

[Merijn B. <me...@il...>]

Quoting Mike Schilli (m...@pe...):
> 
> Yeah, that's an old issue that dates back to Log4perl 0.42: There we
> figured out that if someone wrote
> 
>     $SIG{__DIE__} = sub { print "die handler!\n"; };
> 
> and used Log4perl and some module like Time::HiRes is missing, which
> is acceptable, the handler gets triggered because eval { require }
> causes an exception. Confusion ensued.
> 
Ok, so you have a good reason for attempting this, which is great to
know. I was really wondering why you would do this. 

> Now, I've always thought that this is a bug in perl, nobody writes die
> die handlers 'correctly'. To comply with users who get confused with this
> confusing behaviour, I put this module_available() hack in place, which,
> admittedly, sucks.
> 
;-)

> What to do? Going back to eval { require } would break every user with
> sloppy die handlers.
> 
No, if you read the patch on rt closely, you will see it puts a 'local'
die handler in place, just for the scope of the eval. This will
temporarily override all other die handlers, safely do an eval and then
return the result and unmask the users die handlers afterwards. This is
entirely safe to do and the eval will not trigger the users die handlers
anymore. You can just apply the patch as is and you will not break users
code.

Regards,
-- 
Merijn Broeren | We take risks, we know we take them. Therefore, when things
               | come out against us, we have no cause for complaint.
               | - Scott, last journal entry, march 1912

Re: [log4perl-devel] Problems with uninitialized root-logger in log::log4perl

[Johannes K. <jo....@gm...>]

Hi,

Mike Schilli schrieb:
> On Fri, 23 Nov 2007, Johannes Kilian wrote:
> 
>> Using my "traditional" log4perl configuration file (used from 0.51
>> on) the 1.12 Version shows following behaviour (which I didn't
>> notice with earlier versions ...):
>> 1.) Initializing log4perl works without any errors
>> 2.) Getting loggers works without any errors
>> 3.) Using $logger->logdie(...) (and other functions dieing, like $logger->error_die(...)) makes the program die IMMEDIATELY; I'm not able to catch the die-exception within an eval{} block -> WHY??? - I'm sure it worked with earlier versions of log4perl ..
> 
> Hmm, the following works for me:
> 
>     use Log::Log4perl qw(:easy);
>     Log::Log4perl->easy_init($DEBUG);
> 
>     eval {
> 	LOGDIE "Waah!";
>     };
> 
>     print "Survived!\n";
> 
> and prints
> 
>     2007/11/30 17:38:48 Waah!
>     Survived!
> 
> Do you have a __DIE__ handler defined somewhere by any chance?
> 

No - no __DIE__ handler within my own perl-modules/perl files. Perhaps
there might be some troublesome __DIE__ handler within the officiall
perl modules (installed in Perl\lib or Perl\site\lib) - But how can I
find out which one is it?


> 
>> 4.) Finishing my program an error from log4perl occurs:     (in cleanup) Internal error: Root Logger not initialized. at C:/Programme/Perl/site/lib/Log/Log4perl/Logger.pm line 557 during global destruction.
>>

How can I avoid the internal error above?
Perhaps the uninitialized root logger causes the erroneous exception
handling as described in point 3.)?

Thanks
Johannes

[log4perl-devel] help with different caller depths

[Martin E. <mar...@ea...>]

Hi,

I've used Log::Log4perl for some time (thanks) and also written 
DBIx::Log4perl but the caller_depth is now getting in my way and 
wondered what anyone else did. I have (as an example):

program.pl - this uses Log::Log4perl to log at "myspace::myprogram"

program.pl uses DBIx::Log4perl which logs at "DBIx::Log4perl"

but DBIx::Log4perl is effectively a wrapper around DBI so it sets the 
caller_depth to 2 in DBIx::Log4perl with:

BEGIN {
     # when Log4perl logs where the log message were output get it to
     # ignore the lowest 2 levels of the stack i.e. DBIx::Log4perl.
     $Log::Log4perl::caller_depth = 2;
}

Problem is that this seems to get inherited for all Log4perl instances 
I've got so dies in program.pl show:

[undef]:[undef] main::

instead of:

program.pl:1017 main::

Is it possible to have different caller depths?

Thanks

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Re: [log4perl-devel] Log::Log4Perl::Util::module_available broken...

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

On Thu, 22 Nov 2007, Merijn Broeren wrote:

> There is an existing RT bug for the issue of module_available being
> broken already:
>
> http://rt.cpan.org/Public/Bug/Display.html?id=24884
>
> which is 10 months older then the release done yesterday. Since there
> have been tickets closed since then I am assuming you guys are aware of
> this issue already.

Yeah, that's an old issue that dates back to Log4perl 0.42: There we
figured out that if someone wrote

    $SIG{__DIE__} = sub { print "die handler!\n"; };

and used Log4perl and some module like Time::HiRes is missing, which
is acceptable, the handler gets triggered because eval { require }
causes an exception. Confusion ensued.

Now as it has been pointed out, it's actually the user's fault. A
correct die-Handler checks if it was called because of an eval and
ignores the exception.

Now, I've always thought that this is a bug in perl, nobody writes die
die handlers 'correctly'. To comply with users who get confused with this
confusing behaviour, I put this module_available() hack in place, which,
admittedly, sucks.

What to do? Going back to eval { require } would break every user with
sloppy die handlers.

We could add a load time option to establish the correct behavior:

    use Log::Log4perl qw(:module_check_via_eval);

Other ideas?

-- Mike

Mike Schilli
m...@pe...

>
> I just wanted to reiterate that this code really is broken, both in
> spirit and in implementation. Please reconsider having this broken code
> in such a useful package. The patch in RT is sufficient to restore
> functionality, but I would personally take out all module_available
> calls everywhere from Log4perl and replace it with a simple eval {require }.
>
> To illustrate implementation brokenness, see line 33 of Util.pm:
>
>       ref $dir !~ /^(GLOB|SCALAR|HASH|REF|LVALUE)$/) {
>
> which tries to determine the reference status on the result of a regular
> expression. I assume the author wanted to write this :
>
>       ref($dir) !~ /^(GLOB|SCALAR|HASH|REF|LVALUE)$/) {
>
> but forgot about operator precedence. So this test will *never* be true.
> Which is good, as the code on line 34 inside the if branch is bad as well.
>
>       return 1 if $dir->INC();
>
> as the INC method is supposed to return the open file handle of the file
> requested. Since you do not request a file, the method is under no
> obligation to actually return a true value.
>
> But it would be pointless to try fixing this implementation since
> whatever the result of the module_available function is, it just leads
> to an eval { require } afterwards anyway, so you are doubling the
> effort. It would be very nice if you would consider to modify Log4perl
> to not use module_available. Or accept the RT patch. The current code
> does not work with @INC objects.
>
> Regards,
> --
> Merijn Broeren | We take risks, we know we take them. Therefore, when things
>                | come out against us, we have no cause for complaint.
>                | - Scott, last journal entry, march 1912
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

Re: [log4perl-devel] Problems with uninitialized root-logger in log::log4perl

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

On Fri, 23 Nov 2007, Johannes Kilian wrote:

> Using my "traditional" log4perl configuration file (used from 0.51
> on) the 1.12 Version shows following behaviour (which I didn't
> notice with earlier versions ...):
> 1.) Initializing log4perl works without any errors
> 2.) Getting loggers works without any errors
> 3.) Using $logger->logdie(...) (and other functions dieing, like $logger->error_die(...)) makes the program die IMMEDIATELY; I'm not able to catch the die-exception within an eval{} block -> WHY??? - I'm sure it worked with earlier versions of log4perl ..

Hmm, the following works for me:

    use Log::Log4perl qw(:easy);
    Log::Log4perl->easy_init($DEBUG);

    eval {
	LOGDIE "Waah!";
    };

    print "Survived!\n";

and prints

    2007/11/30 17:38:48 Waah!
    Survived!

Do you have a __DIE__ handler defined somewhere by any chance?

-- Mike

Mike Schilli
m...@pe...

> 4.) Finishing my program an error from log4perl occurs:     (in cleanup) Internal error: Root Logger not initialized. at C:/Programme/Perl/site/lib/Log/Log4perl/Logger.pm line 557 during global destruction.
>
> What's going on? What can I do to make $logger->logdie(...)  to be catchable with eval{} again?
>
> Any help welcome ...
>
> Johannes
>
> As an appendix, my Log4perl-configuration (quite complex):
>
> <?xml version="1.0" encoding="utf-8"?>
> <!DOCTYPE log4perl:configuration SYSTEM "log4perl.dtd">
> <log4perl:configuration xmlns:log4perl="http://log4perl.sourceforge.net/"
>                         threshold="debug"
>                         oneMessagePerAppender="true">
> <!--- *************************************************************************************** -->
> <!-- *** APPENDER ************************************************************************** -->
> <!-- *************************************************************************************** -->
> <log4perl:appender name="AppGeneralFile"
>                    class="Log::Log4perl::Appender::File">
>   <param name="filename"
>          value="sub { Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' =&gt; 'FULL'); };" />
>   <param name="mode"
>          value="write" />
>   <param name="autoflush"
>          value="1" />
>   <filter-ref id="FilterInfo" />
>   <log4perl:layout name="LayoutDateTimeClass"
>                    class="org.apache.log4j.PatternLayout">
>     <param name="ConversionPattern"
>            value="%d %p [%c]: %m%n" />
>   </log4perl:layout>
> </log4perl:appender>
> <log4perl:appender name="AppErrorFile"
>                    class="Log::Log4perl::Appender::File">
>   <param name="filename"
>          value="sub { Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' =&gt; 'ERR'); };" />
>   <param name="mode"
>          value="write" />
>   <param name="autoflush"
>          value="1" />
>   <filter-ref id="FilterErr" />
>   <log4perl:layout name="LayoutDateTimeClass"
>                    class="org.apache.log4j.PatternLayout">
>     <param name="ConversionPattern"
>            value="%d %p [%c]: %m%n" />
>   </log4perl:layout>
> </log4perl:appender>
> <log4perl:appender name="AppGeneralScreen"
>                    class="Log::Log4perl::Appender::Screen">
>   <filter-ref id="FilterInfo" />
>   <log4perl:layout name="LayoutDateTimeClass"
>                    class="org.apache.log4j.PatternLayout">
>     <param name="ConversionPattern"
>            value="%d %p [%c]: %m%n" />
>   </log4perl:layout>
> </log4perl:appender>
> <log4perl:appender name="AppDebugFile"
>                    class="Log::Log4perl::Appender::File">
>   <param name="filename"
>          value="sub { Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' =&gt; 'DEBUG'); };" />
>   <param name="mode"
>          value="write" />
>   <param name="autoflush"
>          value="1" />
>   <filter-ref id="FilterAll" />
>   <log4perl:layout name="LayoutDateTimeClass"
>                    class="org.apache.log4j.PatternLayout">
>     <param name="ConversionPattern"
>            value="%d{HH:mm:ss} [%c] %p: %m%n" />
>   </log4perl:layout>
> </log4perl:appender>
> <log4perl:appender name="AppSqlFile"
>                    class="Log::Log4perl::Appender::File">
>   <param name="filename"
>          value="sub { Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' =&gt; 'SQL'); };" />
>   <param name="mode"
>          value="write" />
>   <param name="autoflush"
>          value="1" />
>   <filter-ref id="FilterAll" />
>   <log4perl:layout name="LayoutDateTimeClass"
>                    class="org.apache.log4j.PatternLayout">
>     <param name="ConversionPattern"
>            value="%d %p [%c]: %m%n" />
>   </log4perl:layout>
> </log4perl:appender>
> <!-- *** FILTER **************************************************************************** -->
> <log4perl:appender name="DebugSyncer"
>                    class="Log::Log4perl::Appender::Synchronized">
>   <param name="appender"
>          value="AppDebugFile" />
> </log4perl:appender>
> <!-- *************************************************************************************** -->
> <!-- *** FILTER **************************************************************************** -->
> <!-- *************************************************************************************** -->
> <log4perl:filter name="FilterAll"
>                  class="Log::Log4perl::Filter::LevelRange">
>   <param name="LevelMin"
>          value="DEBUG" />
>   <param name="LevelMax"
>          value="FATAL" />
>   <param name="AcceptOnMatch"
>          value="true" />
> </log4perl:filter>
> <log4perl:filter name="FilterInfo"
>                  class="Log::Log4perl::Filter::LevelRange">
>   <param name="LevelMin"
>          value="INFO" />
>   <param name="LevelMax"
>          value="FATAL" />
>   <param name="AcceptOnMatch"
>          value="true" />
> </log4perl:filter>
> <log4perl:filter name="FilterErr"
>                  class="Log::Log4perl::Filter::LevelRange">
>   <param name="LevelMin"
>          value="ERROR" />
>   <param name="LevelMax"
>          value="FATAL" />
>   <param name="AcceptOnMatch"
>          value="true" />
> </log4perl:filter>
> <!-- *************************************************************************************** -->
> <!-- *** CATEGORIES ************************************************************************ -->
> <!-- *************************************************************************************** -->
> <root>
>   <priority value="debug" />
>   <appender-ref ref="AppGeneralFile" />
>   <appender-ref ref="AppGeneralScreen" />
>   <appender-ref ref="AppErrorFile" />
> </root>
> <!--- *************************************************************************************** -->
> <category name="dbg"
>           additivity="false">
>   <priority value="debug" />
>   <appender-ref ref="AppDebugFile" />
> </category>
> <category name="sql"
>           additivity="false">
>   <priority value="debug" />
>   <appender-ref ref="AppDebugFile" />
> </category>
> <category name="BMTK">
>   <priority value="info" />
>   <appender-ref ref="AppGeneralFile" />
> </category>
> <category name="Vitronic::BuildDatenbank::Tables"
>           additivity="false">
>   <priority value="info" />
>   <appender-ref ref="AppSqlFile" />
> </category></log4perl:configuration>
>
>
>
>
> --
> GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
> Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
>

[log4perl-devel] Problems with uninitialized root-logger in log::log4perl

[Johannes K. <Jo....@gm...>]

Hi,

I've encounterd a view problems with "uninitialized root-logger" log-log4perl (currently using Version1.12):

System:
ActiveStatePerl 5.8.8.817
WinXP SP2
Log::Log4Perl 1.12

Using my "traditional" log4perl configuration file (used from 0.51 on) the 1.12 Version shows following behaviour (which I didn't notice with earlier versions ...):
1.) Initializing log4perl works without any errors
2.) Getting loggers works without any errors
3.) Using $logger->logdie(...) (and other functions dieing, like $logger->error_die(...)) makes the program die IMMEDIATELY; I'm not able to catch the die-exception within an eval{} block -> WHY??? - I'm sure it worked with earlier versions of log4perl ..
4.) Finishing my program an error from log4perl occurs:     (in cleanup) Internal error: Root Logger not initialized. at C:/Programme/Perl/site/lib/Log/Log4perl/Logger.pm line 557 during global destruction.

What's going on? What can I do to make $logger->logdie(...)  to be catchable with eval{} again?

Any help welcome ...

Johannes

As an appendix, my Log4perl-configuration (quite complex):

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE log4perl:configuration SYSTEM "log4perl.dtd">
<log4perl:configuration xmlns:log4perl="http://log4perl.sourceforge.net/"
                        threshold="debug"
                        oneMessagePerAppender="true">
<!--- *************************************************************************************** -->
<!-- *** APPENDER ************************************************************************** -->
<!-- *************************************************************************************** -->
<log4perl:appender name="AppGeneralFile"
                   class="Log::Log4perl::Appender::File">
  <param name="filename"
         value="sub { Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' =&gt; 'FULL'); };" />
  <param name="mode"
         value="write" />
  <param name="autoflush"
         value="1" />
  <filter-ref id="FilterInfo" />
  <log4perl:layout name="LayoutDateTimeClass"
                   class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern"
           value="%d %p [%c]: %m%n" />
  </log4perl:layout>
</log4perl:appender>
<log4perl:appender name="AppErrorFile"
                   class="Log::Log4perl::Appender::File">
  <param name="filename"
         value="sub { Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' =&gt; 'ERR'); };" />
  <param name="mode"
         value="write" />
  <param name="autoflush"
         value="1" />
  <filter-ref id="FilterErr" />
  <log4perl:layout name="LayoutDateTimeClass"
                   class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern"
           value="%d %p [%c]: %m%n" />
  </log4perl:layout>
</log4perl:appender>
<log4perl:appender name="AppGeneralScreen"
                   class="Log::Log4perl::Appender::Screen">
  <filter-ref id="FilterInfo" />
  <log4perl:layout name="LayoutDateTimeClass"
                   class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern"
           value="%d %p [%c]: %m%n" />
  </log4perl:layout>
</log4perl:appender>
<log4perl:appender name="AppDebugFile"
                   class="Log::Log4perl::Appender::File">
  <param name="filename"
         value="sub { Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' =&gt; 'DEBUG'); };" />
  <param name="mode"
         value="write" />
  <param name="autoflush"
         value="1" />
  <filter-ref id="FilterAll" />
  <log4perl:layout name="LayoutDateTimeClass"
                   class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern"
           value="%d{HH:mm:ss} [%c] %p: %m%n" />
  </log4perl:layout>
</log4perl:appender>
<log4perl:appender name="AppSqlFile"
                   class="Log::Log4perl::Appender::File">
  <param name="filename"
         value="sub { Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' =&gt; 'SQL'); };" />
  <param name="mode"
         value="write" />
  <param name="autoflush"
         value="1" />
  <filter-ref id="FilterAll" />
  <log4perl:layout name="LayoutDateTimeClass"
                   class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern"
           value="%d %p [%c]: %m%n" />
  </log4perl:layout>
</log4perl:appender>
<!-- *** FILTER **************************************************************************** -->
<log4perl:appender name="DebugSyncer"
                   class="Log::Log4perl::Appender::Synchronized">
  <param name="appender"
         value="AppDebugFile" />
</log4perl:appender>
<!-- *************************************************************************************** -->
<!-- *** FILTER **************************************************************************** -->
<!-- *************************************************************************************** -->
<log4perl:filter name="FilterAll"
                 class="Log::Log4perl::Filter::LevelRange">
  <param name="LevelMin"
         value="DEBUG" />
  <param name="LevelMax"
         value="FATAL" />
  <param name="AcceptOnMatch"
         value="true" />
</log4perl:filter>
<log4perl:filter name="FilterInfo"
                 class="Log::Log4perl::Filter::LevelRange">
  <param name="LevelMin"
         value="INFO" />
  <param name="LevelMax"
         value="FATAL" />
  <param name="AcceptOnMatch"
         value="true" />
</log4perl:filter>
<log4perl:filter name="FilterErr"
                 class="Log::Log4perl::Filter::LevelRange">
  <param name="LevelMin"
         value="ERROR" />
  <param name="LevelMax"
         value="FATAL" />
  <param name="AcceptOnMatch"
         value="true" />
</log4perl:filter>
<!-- *************************************************************************************** -->
<!-- *** CATEGORIES ************************************************************************ -->
<!-- *************************************************************************************** -->
<root>
  <priority value="debug" />
  <appender-ref ref="AppGeneralFile" />
  <appender-ref ref="AppGeneralScreen" />
  <appender-ref ref="AppErrorFile" />
</root>
<!--- *************************************************************************************** -->
<category name="dbg"
          additivity="false">
  <priority value="debug" />
  <appender-ref ref="AppDebugFile" />
</category>
<category name="sql"
          additivity="false">
  <priority value="debug" />
  <appender-ref ref="AppDebugFile" />
</category>
<category name="BMTK">
  <priority value="info" />
  <appender-ref ref="AppGeneralFile" />
</category>
<category name="Vitronic::BuildDatenbank::Tables"
          additivity="false">
  <priority value="info" />
  <appender-ref ref="AppSqlFile" />
</category></log4perl:configuration>




-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

[log4perl-devel] Log::Log4Perl::Util::module_available broken...

[Merijn B. <me...@il...>]

Hello,

There is an existing RT bug for the issue of module_available being
broken already:

http://rt.cpan.org/Public/Bug/Display.html?id=24884

which is 10 months older then the release done yesterday. Since there
have been tickets closed since then I am assuming you guys are aware of
this issue already. 

I just wanted to reiterate that this code really is broken, both in
spirit and in implementation. Please reconsider having this broken code
in such a useful package. The patch in RT is sufficient to restore
functionality, but I would personally take out all module_available
calls everywhere from Log4perl and replace it with a simple eval {require }. 

To illustrate implementation brokenness, see line 33 of Util.pm:

	ref $dir !~ /^(GLOB|SCALAR|HASH|REF|LVALUE)$/) {

which tries to determine the reference status on the result of a regular
expression. I assume the author wanted to write this :

	ref($dir) !~ /^(GLOB|SCALAR|HASH|REF|LVALUE)$/) {

but forgot about operator precedence. So this test will *never* be true. 
Which is good, as the code on line 34 inside the if branch is bad as well. 

	return 1 if $dir->INC();

as the INC method is supposed to return the open file handle of the file
requested. Since you do not request a file, the method is under no
obligation to actually return a true value.

But it would be pointless to try fixing this implementation since
whatever the result of the module_available function is, it just leads
to an eval { require } afterwards anyway, so you are doubling the
effort. It would be very nice if you would consider to modify Log4perl
to not use module_available. Or accept the RT patch. The current code
does not work with @INC objects. 

Regards,
-- 
Merijn Broeren | We take risks, we know we take them. Therefore, when things
               | come out against us, we have no cause for complaint.
               | - Scott, last journal entry, march 1912

Re: [log4perl-devel] redirect system command STDERR to log4perl

[John D. <du...@gm...>]

ok, this seems to be the best:
system("command 2>/tmp/stderr.out 1>/tmp/stdout.out");

is there any recommended way how to directly read these files with
log4perl? I would like to append the output directly to output of
logger.

On Nov 22, 2007 12:54 AM, Kevin M. Goess <cp...@go...> wrote:
> John Dunbar wrote:
> > Kevin, thank you for comprehensive reply.
> >
> >> Well, the safest and most direct way would be to replace/augment all the
> >> prints to STDERR (like "warn" and "die") inside your script with
> >> log4perl logger calls.
> >
> > I would prefer this solution, but how can I the redirect whole output
> > (or STDERR atleast) of the external command to die?
> > I am almost perl beginner, sorry, if this question is too easy.
>
> Sorry, I was assuming that this external command was perl code you had
> written.  If it's some other command you don't have access to, then you
> can either wrap it in perl and use temp files to capture the output
>
>    my $stdout = `command 2>/tmp/securetempfile`;
>
> or
>    system("command 2>/tmp/stderr.out 1>/tmp/stdout.out");
>
> (but use File::Temp to create the tempfile names, and keep in mind that
> the tempfiles can be accessed by anyone on that machine).
>
>
> >> Or you could pipe the output of your script to another script that reads
> >> STDIN and implements logging like this:
> >>
> >>  command 2>&1 | perl -e 'use Log::Log4perl qw/:easy/; \
> >>  Log::Log4perl::easy_init($INFO);  \
> >>  while (<STDIN>){INFO $_}'
> >
> > Can I do this in perl script directly?
> >
> >    use Log::Log4perl qw/:easy/;
> >    Log::Log4perl::easy_init($INFO);
> >    $pid = open(STDIN, "ls nonsense 2>/dev/null |");
> >    while (<STDIN>){INFO $_};
>
> See above with the backticks or the system call.
>
> > Is there any way how to redirect STDOUT to INFO and STDERR to ERROR?
> > If both is not possible, STDERROR to ERROR is more important.
>
> The tempfiles is a hacky but fairly reliable way to do it.  See also
> IPC::Open3, where you can get the stdout and stderr of your child
> process on differen handles.
>

Re: [log4perl-devel] redirect system command STDERR to log4perl

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

John Dunbar wrote:
> Kevin, thank you for comprehensive reply.
> 
>> Well, the safest and most direct way would be to replace/augment all the
>> prints to STDERR (like "warn" and "die") inside your script with
>> log4perl logger calls.
> 
> I would prefer this solution, but how can I the redirect whole output
> (or STDERR atleast) of the external command to die?
> I am almost perl beginner, sorry, if this question is too easy.

Sorry, I was assuming that this external command was perl code you had
written.  If it's some other command you don't have access to, then you
can either wrap it in perl and use temp files to capture the output

   my $stdout = `command 2>/tmp/securetempfile`;

or
   system("command 2>/tmp/stderr.out 1>/tmp/stdout.out");

(but use File::Temp to create the tempfile names, and keep in mind that
the tempfiles can be accessed by anyone on that machine).


>> Or you could pipe the output of your script to another script that reads
>> STDIN and implements logging like this:
>>
>>  command 2>&1 | perl -e 'use Log::Log4perl qw/:easy/; \
>>  Log::Log4perl::easy_init($INFO);  \
>>  while (<STDIN>){INFO $_}'
> 
> Can I do this in perl script directly?
> 
>    use Log::Log4perl qw/:easy/;
>    Log::Log4perl::easy_init($INFO);
>    $pid = open(STDIN, "ls nonsense 2>/dev/null |");
>    while (<STDIN>){INFO $_};

See above with the backticks or the system call.

> Is there any way how to redirect STDOUT to INFO and STDERR to ERROR?
> If both is not possible, STDERROR to ERROR is more important.

The tempfiles is a hacky but fairly reliable way to do it.  See also
IPC::Open3, where you can get the stdout and stderr of your child
process on differen handles.

Re: [log4perl-devel] redirect system command STDERR to log4perl

[John D. <du...@gm...>]

Kevin, thank you for comprehensive reply.

> Well, the safest and most direct way would be to replace/augment all the
> prints to STDERR (like "warn" and "die") inside your script with
> log4perl logger calls.

I would prefer this solution, but how can I the redirect whole output
(or STDERR atleast) of the external command to die?
I am almost perl beginner, sorry, if this question is too easy.

>
> Or you could pipe the output of your script to another script that reads
> STDIN and implements logging like this:
>
>  command 2>&1 | perl -e 'use Log::Log4perl qw/:easy/; \
>  Log::Log4perl::easy_init($INFO);  \
>  while (<STDIN>){INFO $_}'

Can I do this in perl script directly?

   use Log::Log4perl qw/:easy/;
   Log::Log4perl::easy_init($INFO);
   $pid = open(STDIN, "ls nonsense 2>/dev/null |");
   while (<STDIN>){INFO $_};

Is there any way how to redirect STDOUT to INFO and STDERR to ERROR?
If both is not possible, STDERROR to ERROR is more important.

Thanks.
-John

Re: [log4perl-devel] redirect system command STDERR to log4perl

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

John Dunbar wrote:
> Now: system "command 2>>errors.log";
> I would like to redirect that error output to logger.

Well, the safest and most direct way would be to replace/augment all the
prints to STDERR (like "warn" and "die") inside your script with
log4perl logger calls.

Or you could pipe the output of your script to another script that reads
STDIN and implements logging like this:

 command 2>&1 | perl -e 'use Log::Log4perl qw/:easy/; \
 Log::Log4perl::easy_init($INFO);  \
 while (<STDIN>){INFO $_}'

Or, if you wanted to get really crazy, if your perl is 5.8.0 or better,
you can use PerlIO::via to grab STDERR and redirect it to your logger.
This is completely untested, and I've never done it myself, but it would
look something like this:
---------------------------------------------
use PerlIO::via::Logger;

use Log::Log4perl;
Log::Log4perl->init(\<<EOL);
log4perl.logger = DEBUG, FileAppndr1

log4perl.appender.FileAppndr1      = Log::Log4perl::Appender::File
log4perl.appender.FileAppndr1.filename = stderr.log
log4perl.appender.FileAppndr1.layout = Log::Log4perl::Layout::SimpleLayout
EOL

close STDERR;
open(STDERR, ">:via(Logger)", '/dev/null');

warn "this is a warning, but stderr is being handled by the logger";
---------------------------------------------
package PerlIO::via::Logger;

use Log::Log4perl qw/:easy/;

sub PUSHED {
     my ($class,$mode,$fh) = @_;
     my $buf = '';
     if ($mode ne 'w'){
        #gah, can't use warn or die if they've closed STDERR!
        print STDOUT "this logger is only usable for writing, mode
'$mode' not allowed";
        exit(1);
    }
     return bless \$buf,$class;
}


sub WRITE {
     my ($obj,$buf,$fh) = @_;
     ERROR("message on stderr: $buf");
     return length($buf);
}

sub FLUSH {
        my ($obj,$fh) = @_;
        #ignoring flush
        return 0;
}

1;
---------------------------------------

[log4perl-devel] redirect system command STDERR to log4perl

[John D. <du...@gm...>]

Dear log4perl users,

I am new to log4perl, I have search quite lot in FAQ and docs, but
didnt't find the answer. How could I redirect the STDERR output of
script executed through system() to logger?
At the moment I use logging to file, but I would like to move it log4perl.

Now: system "command 2>>errors.log";
I would like to redirect that error output to logger.

Thanks a lot
John.

[log4perl-devel] Log::Log4perl 1.14 released

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

Hey all,

Log::Log4perl 1.14 was just released on the Log4perl website. Here's
what's been changed since 1.13:

1.14 (2007/11/18)
    *   (ms) Fixed test suite bug which surfaced in Darwin because
        temporary files contain '++' which freaked out the sloppy
        regex match.
    *   (ms) Better handling of empty config files (reported by
        Robert Raisch)
    *   (ms) Rewrote the Synchronized appender to use semaphores
        exclusivly (got rid of IPC::Shareable).
    *   (ms) Added Log::Log4perl::Util::Semaphore for easy semop
        handling

If all goes well, it'll go to CPAN in a couple of days.

Enjoy!

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] Appender for Net::Syslog

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

Rainaer wrote:
> does [Appender for Net::Syslog] allready exist?  I can't seem to find it if it does?  I'm
> supprised that I cannot find it or that no one has attempted this before.
>  
> Basically I would like to use log4perl to write to a centralized syslog
> that allready exists and is accepting sysloging from other systems.
>
> Any input would be appreaciated?  Are there limitations within
log4perl
> which make this not possible?


Log::Dispatch::Syslog uses the standard unix syslog mechanism which
talks to the local syslogd daemon (see "man 3 syslog".  You can
configure syslogd to forward messages to other hosts via
/etc/syslog.conf, like this:

	local3.*   @my.syslog.host.com

That's the typical unixy way to do it.  I don't see any reason why you
couldn't write a Net::Syslog appender.  The only reason it hasn't been
done is that nobody's needed to, given the above mechanism.

[log4perl-devel] Appender for Net::Syslog

[Rainaer <ra...@gm...>]

does this allready exist?  I can't seem to find it if it does?  I'm
supprised that I cannot find it or that no one has attempted this before.

Basically I would like to use log4perl to write to a centralized syslog that
allready exists and is accepting sysloging from other systems.

Any input would be appreaciated?  Are there limitations within log4perl
which make this not possible?

Thank you.

Robert Zumwalt

Re: [log4perl-devel] questions on log4perl initialzation

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

On Wed, 14 Nov 2007, Joe Wong wrote:

> I came into a very strange behaviour of initializing log4perl. I am
> using mod_perl, with a startup handler (startup.pl). I put
> Log::Log4Perl::init_once(config_file) there. However, when I tried to
> call get_logger() in my module, I got error saying that Log4perl is
> not initialized. How should I init Log4perl in mod_perl environment?

Either in the startup handler or at the request phase:

    http://log4perl.sourceforge.net/d/Log/Log4perl/FAQ.html#792b4

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] questions on log4perl initialzation

[Joe W. <jo...@ou...>]

Hello,

I came into a very strange behaviour of initializing log4perl. I am 
using mod_perl, with a startup handler (startup.pl). I put 
Log::Log4Perl::init_once(config_file) there. However, when I tried to 
call get_logger() in my module, I got error saying that Log4perl is not 
initialized. How should I init Log4perl in mod_perl environment?

Thanks!

- Joe

Re: [log4perl-devel] Log::Log4perl::initialized() but not really?

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

On Wed, 7 Nov 2007, Robert Raisch wrote:

> I'm probably missing something obvious here, but it seems
> counterintuitive to me to have
> 	use Log::Log4perl;
>
> 	my $config = '/dev/null';
>
> 	eval { Log::Log4perl::init($config) };
> 	die "Log::Log4perl::init failed:$@" if $@;

This is a valid configuration, albeit a suspicious one:

    Log::Log4perl configuration looks suspicious: No loggers defined at
    Config.pm line 307.

It's empty, so it does nothing :).

> 	if ( Log::Log4perl::initialized() ) {
> 		Log::Log4perl::get_logger()
> 			->logdie("hmm, log4perl thinks it's been
> initialized");
> 	}
> pass the eval() and then logdie() using an uninitialized logger.

Actually, while this logger doesn't have an appender associated with it,
it is a valid logger.

> Wouldn't it be better to move line 113 in Config.pm
> 	$Log::Log4perl::Logger::INITIALIZED = 1;
> to the end of Log::Log4perl::Config::_init(), after L4p has been
> successfully initialized?

This wouldn't change anything since there's no "return" in between,
right?

That being said, I've found a bug in Config.pm that threw a warning
message on empty configurations, fixed in 1.14.

Thanks for the note ...

-- Mike

Mike Schilli
m...@pe...

>
> Thanks much.
>
> 	Log::Log4perl/1.13, perl 5.8.0, RHEL ES3/Taroon
> 	Log::Log4perl/1.12, ActiveState perl 5.8.8/bin822, WinXP/SP2
>
> --
> Rob Raisch, Financial Media Holdings Group, Inc.
> Publishers of "Compliance Week" -- http://www.complianceweek.com/
>
> -------------------------------------------------------------------------
> 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] appender/dispatcher that writes to per-category files

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

Mike Schilli wrote:
> On Fri, 9 Nov 2007, Jonathan Swartz wrote:
> 
>> My main worry is number of open file handles. Especially with
>> mod_perl, since a lot of those handles will be opened individually in
>> the child processes. Any idea what kind of limits on
>> number of open handles I can expect to hit on a reasonable Unix
>> system?
> 
> Depends. The easiest way to find out is this one:
...
> 
> prints
> 
>     died at 1020 at ./t line 7.
> 
> so that's it :). 


I think he was looking for the total number of open file handles per
system, not per process. Try this:

	cat /proc/sys/fs/file-max

Re: [log4perl-devel] appender/dispatcher that writes to per-category files

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

On Fri, 9 Nov 2007, Jonathan Swartz wrote:

> My main worry is number of open file handles. Especially with
> mod_perl, since a lot of those handles will be opened individually in
> the child processes. At the same time, I don't want to have to open
> and close each handle every time. Any idea what kind of limits on
> number of open handles I can expect to hit on a reasonable Unix
> system?

Depends. The easiest way to find out is this one:

    #!/usr/bin/perl -w
    use strict;
    my @handles;
    my $count;

    while(1) {
	open my $fh, "</etc/passwd" or die "died at $count";
	push @handles, $fh;
	$count++;
    }

prints

    died at 1020 at ./t line 7.

so that's it :). I would suggest that you find a compromise between
good performance and not running out of file handles by having the
appender maintain a configurable pool of file handles that it keeps open.

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] appender/dispatcher that writes to per-category files

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

> So you want a custom appender that dynamically changes the file it's
> writing to. Since the appender's log() function gets  
> 'log4p_category' in
> its %param hash, this should be straight-forward to implement.
>
> Sounds like an interesting idea, I'm looking forward to it!
>

Heh, no doubt. :)

My main worry is number of open file handles. Especially with  
mod_perl, since a lot of those handles will be opened individually in  
the child processes. At the same time, I don't want to have to open  
and close each handle every time. Any idea what kind of limits on  
number of open handles I can expect to hit on a reasonable Unix system?

Re: [log4perl-devel] appender/dispatcher that writes to per-category files

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

On Tue, 6 Nov 2007, Jonathan Swartz wrote:

> >> Right, I expected that new categories would keep cropping up. Why
> >> would it be a problem for an appender to open new filehandles on
> >> the fly? Other than worrying about maximum # of filehandles?
> >
> > Categories are added at init() time, not at log() time. If you add
> > a new
> > category to Log4perl, you have to run init().
>
> Huh? I can add a category at runtime like
>      my $log = Log::Log4perl->get_logger('foo.bar.baz');
> without having declared foo.bar.baz at init() time.

Ah, I see, we're talking about different things. I was talking about
adding categories and associate appenders with them. You're adding
them to the hierarchy and rely on category inheritance.

> I think you mean that categories are associated with appenders at init
> () time, right? But I'm not looking to create a ton of different
> appenders. I'm looking to create a single appender that handles all
> categories, and automatically writes to the right filename based on
> the category passed to log().

So you want a custom appender that dynamically changes the file it's
writing to. Since the appender's log() function gets 'log4p_category' in
its %param hash, this should be straight-forward to implement.

Sounds like an interesting idea, I'm looking forward to it!

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] Log::Log4perl::initialized() but not really?

[Robert R. <RR...@co...>]

Greetings,

I'm probably missing something obvious here, but it seems
counterintuitive to me to have

	#!/usr/bin/perl
	use strict;
	use Log::Log4perl;

	my $config =3D '/dev/null';

	eval { Log::Log4perl::init($config) };
	die "Log::Log4perl::init failed:$@" if $@;
=09
	if ( Log::Log4perl::initialized() ) {
		Log::Log4perl::get_logger()
			->logdie("hmm, log4perl thinks it's been
initialized");
	}
=09
	die "log4perl isn't initialized";

pass the eval() and then logdie() using an uninitialized logger.=20

Wouldn't it be better to move line 113 in Config.pm

	$Log::Log4perl::Logger::INITIALIZED =3D 1;=20

to the end of Log::Log4perl::Config::_init(), after L4p has been
successfully initialized?

Thanks much.

	Log::Log4perl/1.13, perl 5.8.0, RHEL ES3/Taroon
	Log::Log4perl/1.12, ActiveState perl 5.8.8/bin822, WinXP/SP2
=20
--
Rob Raisch, Financial Media Holdings Group, Inc.
Publishers of "Compliance Week" -- http://www.complianceweek.com/

Re: [log4perl-devel] appender/dispatcher that writes to per-category files

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

> On Mon, 5 Nov 2007, Jonathan Swartz wrote:
>
>> Right, I expected that new categories would keep cropping up. Why
>> would it be a problem for an appender to open new filehandles on the
>> fly? Other than worrying about maximum # of filehandles?
>
> Categories are added at init() time, not at log() time. If you add  
> a new
> category to Log4perl, you have to run init().

Huh? I can add a category at runtime like

     my $log = Log::Log4perl->get_logger('foo.bar.baz');

without having declared foo.bar.baz at init() time.

I think you mean that categories are associated with appenders at init 
() time, right? But I'm not looking to create a ton of different  
appenders. I'm looking to create a single appender that handles all  
categories, and automatically writes to the right filename based on  
the category passed to log().

Jon