log4perl-devel — Ongoing log4perl development

Re: [log4perl-devel] Level::is_valid() vs Logger::level()

[Kevin G. <ke...@go...>]

Jonathan, you're absolutely correct.  I just checked into CVS a change 
very similar to your proposed patch, thanks for the find, the 
suggestion, and the help!

      if(defined $level) {
          croak "invalid level '$level'"
                  unless Log::Log4perl::Level::is_valid($level);
+        if ($level =~ /\D/){
+            $level = Log::Log4perl::Level::to_priority($level);
+        }
          $self->{level} = $level;



Jonathan Manning wrote:
> Hello,
> 
> It seems that a textual log level ('INFO' vs $INFO) is accepted by 
> Log::Log4Perl::Level::is_valid().
> 
> So, if I call: $log->level('INFO');
> The string 'INFO' passes is_valid(), and becomes that logger's level.
> But, level() doesn't do any conversion back the the numerical form, so 
> what follows is lots of non-numeric comparison with <= errors.
> 
> I know you're *supposed* to import the levels and call 
> $log->level($INFO) instead, but it seems like a flaw for the string form 
> to be accepted by is_valid, but not work as a logging level.
> Personally, I would prefer it if $log->level() just accepted the text 
> string, and did the conversion to the numeric form for me.
> 
> I do see in the CVS log that this was a recent change to is_valid, so 
> maybe it's there for a reason and these changes are already planned.
> Perhaps this is too unlike Log4J, so that makes it a design decision on 
> whether to accept the text string or not - completely your call.
> 
> Either way, a quick patch is provided below. It passes 'make test', 
> though no test specifically tests the string forms of the levels - I'll 
> go through the trouble to do this if this patch is approved.
> 
> I'd be interested to hear any suggestions/counter-arguments.
> 
> ~Jonathan
> 
> 
> 
> --- Logger.pm.orig      Sun Jul 20 15:34:08 2003
> +++ Logger.pm   Thu Oct  2 17:11:06 2003
> @@ -362,7 +362,11 @@
>      if(defined $level) {
>          croak "invalid level '$level'"
>                  unless Log::Log4perl::Level::is_valid($level);
> -        $self->{level} = $level;
> +       if($level =~ /[A-Z]/) {
> +         $self->{level} = ${Log::Log4perl::Level::PRIORITY{$level}};
> +       } else {
> +         $self->{level} = $level;
> +       }
> 
>          &reset_all_output_methods
>              unless $dont_reset_all;  #keep us from getting overworked
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel

-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217

[log4perl-devel] Re: ??? DB-Connect for Log4Perl via DBI ???

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

Jens, I'm cc'ing this response to our mailing list in case anybody else 
might find it helpful.  That's a better place to post things, somebody 
else might be able to field the question if I'm not available 
(http://lists.sourceforge.net/lists/listinfo/log4perl-devel)

 > I've problems with db connect and can only guess the meaning of
 > parameter "datasource" in logger initialization.

For a description of "datasource" Check out the DBI docs, 'perldoc DBI' 
under "Class Methods" or 
http://www.perldoc.com/perl5.6.1/lib/DBI.html#DBI-Class-Methods

The specifics depend on your particular database, so you might also 
check out 'perldoc DBD::Oracle' (I don't have access to Oracle right 
now, sorry).

I'll update the documentation in the log4perl module to mention the same.

Let us know how it goes, good luck.


Schmidtchen, Jens wrote:
> Hello,
> 
> can you PLEASE give me some advice on HOW TO get logging through DBI to 
> work?
> 
> I've problems with db connect and can only guess the meaning of 
> parameter "datasource" in logger initialization. The only example I've 
> found so far (the one where I've got your email address from) looks like 
> that:
> 
> log4j.appender.DBAppndr.datasource = DBI:CSV:f_dir=t/tmp
> 
> There 's no further explanation for "datasource". I've tried an entry 
> from my local ORACLE tnsname.ora file and got:
> 
> Can't connect(<my_oracle_tnsname> <my_oracle_user> <my_password>), no 
> database driver specified and DBI_DSN env var not set at 
> C:/Programme/Perl/site/lib/Log/Log4perl/Appender/DBI.pm line 83
> 
> Can you please check the attached sources and provide me with a 
> appropriate fix?
> 
> Thank you very much in advance.
> Best regards.
> 
> Jens
> 
> <<log4perldbi.l4p>> <<log4perldbi.pl>>
> 

-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217

[log4perl-devel] Re: ??? DB-Connect for Log4Perl via DBI ???

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

Jens, I'm cc'ing this response to our mailing list in case anybody else 
might find it helpful.  That's a better place to post things, somebody 
else might be able to field the question if I'm not available 
(http://lists.sourceforge.net/lists/listinfo/log4perl-devel)

 > I've problems with db connect and can only guess the meaning of
 > parameter "datasource" in logger initialization.

For a description of "datasource" Check out the DBI docs, 'perldoc DBI' 
under "Class Methods" or 
http://www.perldoc.com/perl5.6.1/lib/DBI.html#DBI-Class-Methods

The specifics depend on your particular database, so you might also 
check out 'perldoc DBD::Oracle' (I don't have access to Oracle right 
now, sorry).

I'll update the documentation in the log4perl module to mention the same.

Let us know how it goes, good luck.

Schmidtchen, Jens wrote:
> Hello,
> 
> can you PLEASE give me some advice on HOW TO get logging through DBI to 
> work?
> 
> I've problems with db connect and can only guess the meaning of 
> parameter "datasource" in logger initialization. The only example I've 
> found so far (the one where I've got your email address from) looks like 
> that:
> 
> log4j.appender.DBAppndr.datasource = DBI:CSV:f_dir=t/tmp
> 
> There 's no further explanation for "datasource". I've tried an entry 
> from my local ORACLE tnsname.ora file and got:
> 
> Can't connect(<my_oracle_tnsname> <my_oracle_user> <my_password>), no 
> database driver specified and DBI_DSN env var not set at 
> C:/Programme/Perl/site/lib/Log/Log4perl/Appender/DBI.pm line 83
> 
> Can you please check the attached sources and provide me with a 
> appropriate fix?
> 
> Thank you very much in advance.
> Best regards.
> 
> Jens
> 
> <<log4perldbi.l4p>> <<log4perldbi.pl>>
> 

-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217

[log4perl-devel] Re: ??? DB-Connect for Log4Perl via DBI ???

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

Jens, I'm cc'ing this response to our mailing list in case anybody else 
might find it helpful.  That's a better place to post things, somebody 
else might be able to field the question if I'm not available 
(http://lists.sourceforge.net/lists/listinfo/log4perl-devel)

 > I've problems with db connect and can only guess the meaning of
 > parameter "datasource" in logger initialization.

For a description of "datasource" Check out the DBI docs, 'perldoc DBI' 
under "Class Methods" or 
http://www.perldoc.com/perl5.6.1/lib/DBI.html#DBI-Class-Methods

The specifics depend on your particular database, so you might also 
check out 'perldoc DBD::Oracle' (I don't have access to Oracle right 
now, sorry).

I'll update the documentation in the log4perl module to mention the same.

Let us know how it goes, good luck.



Schmidtchen, Jens wrote:
> Hello,
> 
> can you PLEASE give me some advice on HOW TO get logging through DBI to 
> work?
> 
> I've problems with db connect and can only guess the meaning of 
> parameter "datasource" in logger initialization. The only example I've 
> found so far (the one where I've got your email address from) looks like 
> that:
> 
> log4j.appender.DBAppndr.datasource = DBI:CSV:f_dir=t/tmp
> 
> There 's no further explanation for "datasource". I've tried an entry 
> from my local ORACLE tnsname.ora file and got:
> 
> Can't connect(<my_oracle_tnsname> <my_oracle_user> <my_password>), no 
> database driver specified and DBI_DSN env var not set at 
> C:/Programme/Perl/site/lib/Log/Log4perl/Appender/DBI.pm line 83
> 
> Can you please check the attached sources and provide me with a 
> appropriate fix?
> 
> Thank you very much in advance.
> Best regards.
> 
> Jens
> 
> <<log4perldbi.l4p>> <<log4perldbi.pl>>
> 

-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217

Re: [log4perl-devel] how to install log4perl for windows

[Kevin G. <ke...@go...>]

First read about ppm 
http://ASPN.ActiveState.com/ASPN/docs/Komodo/tutorial/perltut/perltutppm.html
then read this
http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl/FAQ.html#how_can_i_install_log__log4perl_on_microsoft_windows


Thutika, Srinivas (ODC - Satyam) wrote:
> Hi friends,
> 
> i am new to perl programming.
> 
> i have to USE logging proces in perl...i wanna use log4perl.
> 
> pls let me know how to install it in windows.
> 
> 
> 
> 
>>--Thanks& Regards
>>Srinivas Thutika
>>
>>
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel

-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217

[log4perl-devel] how to install log4perl for windows

[Thutika, S. (O. - Satyam) <STh...@Sa...>]

Hi friends,

i am new to perl programming.

i have to USE logging proces in perl...i wanna use log4perl.

pls let me know how to install it in windows.



> --Thanks& Regards
> Srinivas Thutika
> 
> 
> 

[log4perl-devel] Log::Log4perl 0.38 released to CPAN

[<msc...@ao...>]

Hi all,

0.38 is on its way to CPAN, here's the changelog:

0.38 (09/29/2003)
    * (kg) fixed bug where custom_levels beneath DEBUG didn't work
    * (ms) fixed 5.00305 incompatibility reported by 
      Brett Rann  (constants with leading _).
    * (ms) Log::Log4perl->easy_init() now calls ->reset() first to make sure
      it's not duplicating the existing logging environment. Thanks
      to William McKee  for bringing this up.
    * (ms) fixed bug with error_die() - printed the wrong function/line/file.
      Reported by Brett Rann .
    * (ms) added %T to PatternLayout as a stack traced as suggested by
      Brett Rann .

-- Mike

############################
# Mike Schilli             #
# log...@pe... #
# http://perlmeister.com   #
# log4perl.sourceforge.net #
############################

Re: [log4perl-devel] No ppd

[Mike S. <msc...@ao...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<font face="Arial,sans-serif"><font size="2"><span type="cite">Januski,
Ken wrote:</span>
</font></font>
<p><font face="Arial,sans-serif" size="2"></font></p>
<blockquote type="cite" ><font  face="Arial,sans-serif" size="2"></font><font size="2" face="Arial">Just
wanted to let you know that following
instructions on web page for installation of ppm for log4perl I've had
absolutely no success. </font></blockquote>
<font face="Arial,sans-serif"><font size="2">Did you follow the process
as described in<br>
<a class="moz-txt-link-freetext" href="http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl/FAQ.html#how_can_i_install_log__log4perl_on_microsoft_windows">http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl/FAQ.html#how_can_i_install_log__log4perl_on_microsoft_windows</a><br>
? If yes, please let me know which version of ActiveState you're using.<br>
<br>
<span>-- <br>
-- Mike<br>
Mike Schilli<br>
<a class="moz-txt-link-abbreviated" href="mailto:m...@pe...">m...@pe...</a></span></font></font>
</body>
</html>

[log4perl-devel] No ppd

[Januski, K. <kja...@ph...>]

Hi,

Just wanted to let you know that following instructions on web page for
installation of ppm for log4perl I've had absolutely no success. Now I know
ppm is very, very touchy so it may be ppm and not you. 

I've tried:
ppm install http://log4perl.sourceforge.net/ppm/Log-Log4perl over and over
without sucess. Sometimes I use single quotes, sometimes double, sometimes I
include ppd in address and sometimes I don't. But no matter what I do I
always get the "no PPD found error." And of course it is at that address.

As I said this may just be a ppm problem. But in case it's not I thought I'd
let you know.

Thanks,

Ken 

Re: Re[4]: [log4perl-devel] Patch for default config file (v0.37)

[Mike S. <msc...@ao...>]

Roland Bauer wrote:

 > Calling init without an argument does not seem to work, even if I use
 > ":easy" ... or did I misunderstand your information?

You still have to call init(...) with the usual parameters. (:easy) just 
imports the macros in addition.

-- 
-- Mike
Mike Schilli
m...@pe...

[log4perl-devel] Level::is_valid() vs Logger::level()

[Jonathan M. <jma...@al...>]

Hello,

It seems that a textual log level ('INFO' vs $INFO) is accepted by 
Log::Log4Perl::Level::is_valid().

So, if I call: $log->level('INFO');
The string 'INFO' passes is_valid(), and becomes that logger's level.
But, level() doesn't do any conversion back the the numerical form, so 
what follows is lots of non-numeric comparison with <= errors.

I know you're *supposed* to import the levels and call 
$log->level($INFO) instead, but it seems like a flaw for the string form 
to be accepted by is_valid, but not work as a logging level.
Personally, I would prefer it if $log->level() just accepted the text 
string, and did the conversion to the numeric form for me.

I do see in the CVS log that this was a recent change to is_valid, so 
maybe it's there for a reason and these changes are already planned.
Perhaps this is too unlike Log4J, so that makes it a design decision on 
whether to accept the text string or not - completely your call.

Either way, a quick patch is provided below. It passes 'make test', 
though no test specifically tests the string forms of the levels - I'll 
go through the trouble to do this if this patch is approved.

I'd be interested to hear any suggestions/counter-arguments.

~Jonathan



--- Logger.pm.orig      Sun Jul 20 15:34:08 2003
+++ Logger.pm   Thu Oct  2 17:11:06 2003
@@ -362,7 +362,11 @@
      if(defined $level) {
          croak "invalid level '$level'"
                  unless Log::Log4perl::Level::is_valid($level);
-        $self->{level} = $level;
+       if($level =~ /[A-Z]/) {
+         $self->{level} = ${Log::Log4perl::Level::PRIORITY{$level}};
+       } else {
+         $self->{level} = $level;
+       }

          &reset_all_output_methods
              unless $dont_reset_all;  #keep us from getting overworked

Re[4]: [log4perl-devel] Patch for default config file (v0.37)

[Roland B. <rol...@ff...>]

On Tue, 30 Sep 2003 17:48:15 -0700 Mike Schilli <msc...@ao...> wrote:

MS> Roland Bauer wrote:
MS> 
MS>  > If I wrote init("$ENV{HOME}/log4perl.conf") this would be portable
MS>  > neither.
MS>  > It would be just *my* modules fault instead of Log4perl's fault ;-)
MS> 
MS> Exactly. What do you gain by omitting the path and relying on a
MS> default? 
MS> We can certainly discuss this, I'm just not (yet) seeing the benefit.
MS> Do 
MS> you have a scenario?

I think defaults are mostly a good idea. They make things easier where
you do not need full control. For most situations I personally would like
to use the same configuration. So a default would be nice (for me).



MS> there's two different ways to use qw(:easy):
MS> 
MS> 1) use qw(:easy) and easy_init() - one-parameter-init plus macros
MS> 2) use qw(:easy) and init() - just use the DEBUG(), ERROR(), ... macros

Calling init without an argument does not seem to work, even if I use
":easy" ... or did I misunderstand your information?

Regards
Roland

Re: Re[2]: [log4perl-devel] Patch for default config file (v0.37)

[Mike S. <msc...@ao...>]

Roland Bauer wrote:

 > If I wrote init("$ENV{HOME}/log4perl.conf") this would be portable
 > neither.
 > It would be just *my* modules fault instead of Log4perl's fault ;-)

Exactly. What do you gain by omitting the path and relying on a default? 
We can certainly discuss this, I'm just not (yet) seeing the benefit. Do 
you have a scenario?

 > >2) Is the function easy_init really necessary? Or - at least - could
 > >init accept the same parameters?
 > >
 > >The following syntax seems ok:
 > >
 > >init($filename);
 > >init(\$config_text);
 > >init(\%key_value_pairs);
 > >init($url);
 > >
 > >easy_init($ERROR); # where the string contains a number
 > >easy_init(\%key_value_pairs);
 > >easy_init(\%key_value_pairs_1, \%key_value_pairs_2, ...);
 > >
 > >If I am switching from
 > >"easy" usage to "standard" usage, I have to
 > >a) remove ':easy'
 > >b) change easy_init to init
 > >c) have to supply a config file name
 > >
 > >I'd like to omit step b) and c)  ;-)
 > >
 > >Summary:
 > >- the call of init without parameters should be ok (a default config
 > >  file should be searched
 > >- importing ':easy' should signal that the user wants "easy" usage
 > >- init should accept $DEBUG, ... as parameters (if ":easy" has been
 > imported)

Sorry -- I did miss this question in your previous email. Actually, 
there's two different ways to use qw(:easy):

1) use qw(:easy) and easy_init() - one-parameter-init plus macros
2) use qw(:easy) and init() - just use the DEBUG(), ERROR(), ... macros

I don't see an easy way of consolidating the two (and, we need to 
maintain backwards-compatibility).

-- 
-- Mike
Mike Schilli
m...@pe...

[log4perl-devel] Log::Log4perl 0.38 on homepage

[<msc...@ao...>]

Hi all,

0.38 is on log4perl.sourceforge.net now -- all known bugs should be fixed. Here's what's changed:

0.38 (9/29/2003)
    * (kg) fixed bug where custom_levels beneath DEBUG didn't work
    * (ms) fixed 5.00305 incompatibility reported by
      Brett Rann <bre...@ma...> (constants with leading _).
    * (ms) Log::Log4perl->easy_init() now calls ->reset() first to make sure
      it's not duplicating the existing logging environment. Thanks
      to William McKee <wi...@kn...> for bringing this up.
    * (ms) fixed bug with error_die() - printed the wrong function/line/file.
      Reported by Brett Rann <bre...@ma...>.
    * (ms) added %T to PatternLayout as a stack traced as suggested by
      Brett Rann <bre...@ma...>.

Let me know if you find any weirdness!

-- Mike

############################
# Mike Schilli             #
# log...@pe... #
# http://perlmeister.com   #
# log4perl.sourceforge.net #
############################

Re[2]: [log4perl-devel] Patch for default config file (v0.37)

[Roland B. <rol...@ff...>]

On Fri, 26 Sep 2003 23:15:36 -0700 Mike Schilli <msc...@ao...> wrote:

MS> Roland Bauer wrote:
MS> 
MS>  > The following patch will make "$ENV{HOME}/log4perl.conf"
MS>  > the default file for the init method if it is called
MS>  > without parameters. What do you think about having a default
MS>  > config file?
MS> 
MS> Hmm, Kevin and I talked about this a bit, turns out that $ENV{HOME} 
MS> isn't portable (Win32, Mac?). Also, I don't think log4j has anything 
MS> like this (probably for the same reason). And it's no hassle to write 
MS> init("$ENV{HOME}/log4perl.conf") if you really want this file name as
MS> a 
MS> default -- so, sorry, I'd rather leave that up to the application to 
MS> decide. Hope that's ok with you -- but keep the suggestions coming! :)

You are right, $ENV{HOME} is not portable, however, many CPAN modules
rely on that so the Windows people have to cope with this situation and
there are attempts to give a solution, e. g. some CPAN-Modules
   - User
   - File::HomeDir

BTW, the lack of some environment variables in Windows is a big problem
and I'd really liked a portable Perl solution. Maybe a module
Env::Portable with Env::Portable::Win32, ... (like File::Spec).

If I wrote init("$ENV{HOME}/log4perl.conf") this would be portable neither.
It would be just *my* modules fault instead of Log4perl's fault ;-)

Maybe the default mechanism with $ENV{HOME} could be supported if
and only if $ENV{HOME} is defined? 

Another suggestion were to support an environment variable which keeps
the name of the default config file (see my posting from Sun, 21 Sep 2003):

>From http://jakarta.apache.org/log4j/docs/manual.html:
>"In case the system property log4j.configuration is not defined, 
>then set the string variable resource to its 
>default value "log4j.properties"."

Maybe $ENV{log4j_configuration}? $ENV{LOG4PERL_CONFIGURATION}?

It could be easily implemented. However, as you pointed out, it's
an important conceptual decision what defaults should be supported and
in what way. The question is how Java system properties can/should be
supported in Perl.

What do you think about my second wish (from posting mentioned before):

>2) Is the function easy_init really necessary? Or - at least - could
>init accept the same parameters?
>
>The following syntax seems ok:
>
>init($filename); 
>init(\$config_text);
>init(\%key_value_pairs);
>init($url);
>
>easy_init($ERROR); # where the string contains a number
>easy_init(\%key_value_pairs);
>easy_init(\%key_value_pairs_1, \%key_value_pairs_2, ...);
>
>If I am switching from
>"easy" usage to "standard" usage, I have to 
>a) remove ':easy'
>b) change easy_init to init
>c) have to supply a config file name
>
>I'd like to omit step b) and c)  ;-)
>
>Summary:
>- the call of init without parameters should be ok (a default config
>  file should be searched
>- importing ':easy' should signal that the user wants "easy" usage
>- init should accept $DEBUG, ... as parameters (if ":easy" has been imported) 

Thanks for your patience ;-)

Roland

[log4perl-devel] Re: DBI test cases show errors

[Kevin G. <ke...@go...>]

 >> looks like something's not ok with the DBI test cases ... t/034DBI.t
 >> shows a bunch of errors. Any file not yet checked in perhaps?
 >
 > I see, SQL::Statement seems to have been changed significantly recently,
 > if you don't run 1.00x (like I did), the tests fail. I changed 034DBI.t
 > to ask for 1.005.


Actually, I think it was DBD::CSV, I made some changes to 034DBI.t 
testing them against a more recent DBD::CSV, the changes break under the 
older versions.  I've fixed the test script to work under both old and 
new expectations, and checked it in, fixes are shown below.


      eval {
          require DBD::CSV;
          require SQL::Statement;
-        die "" if $SQL::Statement::VERSION < 1.005;
+        #die "" if $SQL::Statement::VERSION < 1.005;
      };
      if ($@) {
          print STDERR "DBD::CSV or SQL::Statement 1.005 not installed, 
skipping tests\n";
@@ -112,6 +112,8 @@
  EOL
    $got =~ s/[^\w ,"()]//g;  #silly DBD_CSV uses funny EOL chars
    $expected =~ s/[^\w ,"()]//g;
+  $got = lc $got;  #accounting for variations in DBD::CSV behavior
+  $expected = lc $expected;
    ok($got, $expected);
  }

@@ -132,6 +134,8 @@
    $expected =~ s/[^\w ,"()]//g;
    $got =~ s/HASH\(.+?\)//;
    $expected =~ s/HASH\(.+?\)//;
+  $got = lc $got;  #accounting for variations in DBD::CSV behavior
+  $expected = lc $expected;
    ok($got, $expected);
  }

@@ -174,12 +178,12 @@
  $stmt = <<EOL;
      CREATE TABLE log4perltest (
        loglevel     char(9) ,
-      message   char(128),
+      message   char(128)

    )
  EOL

-$dbh->do($stmt);
+$dbh->do($stmt) || die "do failed on $stmt".$dbh->errstr;


  $config = <<'EOT';
@@ -220,6 +224,8 @@
  EOL
    $got =~ s/[^\w ,"()]//g;  #silly DBD_CSV uses funny EOL chars
    $expected =~ s/[^\w ,"()]//g;
+  $got = lc $got;  #accounting for variations in DBD::CSV behavior
+  $expected = lc $expected;
    ok($got, $expected);
  }

> 
> -- 
> -- Mike
> Mike Schilli
> m...@pe...

-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217

Re: [log4perl-devel] bug? error_die %l PatternLayout reports error_die line instead of caller line

[Mike S. <msc...@ao...>]

Brett Rann wrote:

 > When using a pattern layout with %l, calls to error_die report the
 > error_die line details instead of the calling line details:

Fixed in CVS.

 > Also, the path seems inconsistant.  Error die reports the full path,
 > log die reports just the filename  (this is also true for %F).  Also,
 > with the DBI appender it reports the full path for all log types, but
 > file apender reports just the filename.  It would be nice for it to be
 > standardized.  Perhaps %f for the short filename, and %F for the full?

Actually, %F is always the full path, if you just want the filename, 
%F{1} will cut it.

Thanks!

-- 
-- Mike
Mike Schilli
m...@pe...

Re: [log4perl-devel] Patch for default config file (v0.37)

[Mike S. <msc...@ao...>]

Roland Bauer wrote:

 > The following patch will make "$ENV{HOME}/log4perl.conf"
 > the default file for the init method if it is called
 > without parameters. What do you think about having a default
 > config file?

Hmm, Kevin and I talked about this a bit, turns out that $ENV{HOME} 
isn't portable (Win32, Mac?). Also, I don't think log4j has anything 
like this (probably for the same reason). And it's no hassle to write 
init("$ENV{HOME}/log4perl.conf") if you really want this file name as a 
default -- so, sorry, I'd rather leave that up to the application to 
decide. Hope that's ok with you -- but keep the suggestions coming! :)

-- 
-- Mike
Mike Schilli
m...@pe...

Re: [log4perl-devel] logging to a file and forking

[Mike S. <msc...@ao...>]

Viner, David wrote:

 > I want to use a file-based logger, like
 > Log::Dispatch::File
 > or something similar, and have a logger object initialized in a parent
 > process.  When the parent forks a child, that child process will have
 > a copy
 > of the logger object.  Can I safely use that duplicate logger object
 > in the
 > child?

If you use the same appender in different processes or threads, and the 
appender doesn't take any precautions to separate the messages, they'll 
end up randomly interleaved.

To avoid this, you could

* write a new file appender that obtains a mutex lock before it writes 
(but that's going to be slow)
* use different appenders for different processes

-- 
-- Mike
Mike Schilli
m...@pe...

[log4perl-devel] log4perl-devel-request@lists.sourceforge.net

[Duffy, B. (OFT) <Bri...@of...>]

log...@li...

RE: [log4perl-devel] use strict and JavaMap::RollingFileAppender problem

[Mark P. <ma...@ml...>]

I have just uploaded Log-Dispatch-FileRotate-1.11.tar.gz to PAUSE.

The changes are slight:

   1.11 Thu Sep 25 11:18:04 EST 2003
	- Forgot to update the Doco from 1.10.
	- Added some missing log4j recurrence patterns and made them
	  case insensitive

The doco update removes the missleading comment regarding the 'size'
field. It used to say the size was specified in megs which it isn't.

The second change allows for more log4j types of recurrance
specifications. The following (case insensitive) is now allowed. I didn't
want to remove the original ones (which were wrong) just in case someone
was using them.

        'yyyy-mm'           # Every Month
        'yyyy-ww'           # Every week
        'yyyy-dd'           # Every day 
        'yyyy-mm-dd'        # Every day 
        'yyyy-dd-a'         # Every day 12noon
        'yyyy-mm-dd-a'      # Every day 12noon
        'yyyy-dd-hh'        # Every hour
        'yyyy-mm-dd-hh'     # Every hour
        'yyyy-dd-hh-mm'     # Every minute
        'yyyy-mm-dd-hh-mm'  # Every minute

So yyyy-MM-dd-hh should now do the right thing.

cheers
markpf

[log4perl-devel] Patch for default config file (v0.37)

[Roland B. <rol...@ff...>]

The following patch will make "$ENV{HOME}/log4perl.conf"
the default file for the init method if it is called
without parameters. What do you think about having a default
config file? - Roland

#-------------------------------------
--- Config.pm_org        Mon Aug 11 07:03:28 2003
+++ Config.pm        Thu Sep 25 23:07:31 2003
@@ -495,6 +495,12 @@
                      $res->message." ";
             }
         }else{
+            unless (defined $config) {
+                my $default = "$ENV{HOME}/log4perl.conf";
+                # BETTER:
+                # my $default = catfile($ENV{HOME} || die, 'log4perl.conf');
+                $config = $default if -f $default;
+            }
             open FILE, "<$config" or die "Cannot open config file '$config'";
             @text = <FILE>;
             close FILE;

#-------------------------------------


-- 
Roland Bauer
http://www.fff.at/contact/ 

Re: [log4perl-devel] Bug report and patch (Log4perl/Appender/DBI.pm)

[Kevin G. <ke...@go...>]

Brett, you are absolutely correct.  Thanks for the find and the
analysis.  I've checked in the fix and checked in some tests to work the
usePreparedStatement option a little bit.  


Brett Rann wrote:
> 
> Log4perl/Appender/DBI.pm  (exists in v0.37)
> 
> PROBLEM:
> When a database appender is used and preparedStatement is set, Appender/DBI.pm incorrectly warns that bufferSize has been specified when it has not.  Happens also if bufferSize is set to 1, 0 or <blank> (guesses at sensible values), but that is reasonable.
> 
> ANALASYS:
> Incorrect logic for checking if bufferSize has been set:
> 
> Pasted from about line 33.
> --------------
> *    $self->{BUFFERSIZE} = $p{bufferSize} || 1;_
> 
>     if ($p{usePreparedStmt}) {
>         $self->{sth} = $self->create_statement($p{sql});
> **        $self->{usePreparedStmt} = 1;
>     }else{
>         $self->{layout} = Log::Log4perl::Layout::PatternLayout->new(
>                     {ConversionPattern => {value  => $p{sql}}});
>     }
> 
> ***    if ($self->{usePreparedStmt} &&  $self->{BUFFERSIZE}){
>         warn "Log4perl: you've defined both usePreparedStmt and bufferSize \n".
>         "in your appender '$p{name}'--\n".
>         "I'm going to ignore bufferSize and just use a prepared stmt\n";
>     }
> 
>     return $self;
> }
> -------------
> 
> The warning at line *** will always print if usePreparedStmt has been set, because, in the || at line *,  $self->{BUFFERSIZE} gets defaulted to 1 if it is undefined, zero or otherwise false.
> 
> PATCH:
> Change *** to read
> If ($self->{usePreparedStmt} && $p{bufferSize}) {
> 
> Or possibly unset BUFFERSIZE after line **.  I have gone with the first change though because it fixes the problem without making other assumptions (that unsetting it will not break countless bits of code elsewhere).
> 
> Regards,
> Brett
> --
> 
> --
> __________________________________________________________
> Sign-up for your own personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
> 
> CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
> http://corp.mail.com/careers
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel

--
Happy Trails. . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510)525-5217

Re: [log4perl-devel] Multiple messages when module reloaded by Apache::Reload

[William M. <wi...@kn...>]

On Wed, Sep 24, 2003 at 05:04:20PM -0700, Kevin Goess wrote:
> William, if I'm understanding you correctly, you're calling Log4perl's 
> init() function inside a subroutine, and calling it repeatedly? 
> Log4perl works from singleton objects that are global to the entire 
> interpreter (package globals), so each perl interpreter only needs to 
> call init() once in its lifetime.  Subsequent calls to 
> get_logger('somecategory') retrieve the same loggers from the hoard of 
> singletons.
> 
> Does that make sense?

Yep. It's the persistant environment that's causing some confusion for
me. I'm following the first example from your article (great job btw!)
at Perl.com. I've revised my subroutine to test for an existing logger
before calling init again.

William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: [log4perl-devel] Multiple messages when module reloaded by Apache::Reload

[Kevin G. <ke...@go...>]

William, if I'm understanding you correctly, you're calling Log4perl's 
init() function inside a subroutine, and calling it repeatedly? 
Log4perl works from singleton objects that are global to the entire 
interpreter (package globals), so each perl interpreter only needs to 
call init() once in its lifetime.  Subsequent calls to 
get_logger('somecategory') retrieve the same loggers from the hoard of 
singletons.

Does that make sense?


William McKee wrote:
> Hi Mike,
> 
> Thanks for the prompt reply! Indeed inserting the reset worked.
> 
> I discovered that the behavior occurs each time I ran my subroutine, not
> just when Apache::Reload got called. Given your explanation, this
> behavior makes sense because I am calling init each time it is run.
> 
> So the init function currently creates a new logger object, and I'm
> basically firing off new ones every time my script runs. It's like a
> giant fireworks show (which is also what my logs start to look like
> after several runs <g>).
> 
> Regards,
> William
> 

-- 
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217