log4perl-devel — Ongoing log4perl development

Re: [log4perl-devel] Revisit of database logging when database connection fails

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

On Thu, 4 Jan 2007, Robert Jacobson wrote:

> LOL!  I always do this -- when I've explained the problem to someone
> else, I figure it out myself soon after!

That's the kind of problem I like hearing about :).

> My DBI_wrapper.pm is mimicking Appender::DBI already, in that it does
> _init() (connects to the database) on new() and calls
> Appender::DBI::log() to log the message.
>
> I can change my new() to *not* call _init(); instead, I call _init()
> right before Appender::DBI::log(), then I disconnect.

By the way, you might want to take a look at

   mysql_auto_reconnect
	  This attribute determines whether DBD::mysql will automatically
	  reconnect to mysql if the connection be lost. This feature
	  defaults to off; however, if either the GATEWAY_INTERFACE or
	  MOD_PERL envionment variable is set, DBD::mysql will turn
	  mysql_auto_reconnect on.  Setting mysql_auto_reconnect to on is
	  not advised if 'lock tables' is used because if DBD::mysql
	  reconnect to mysql all table locks will be lost.  This attribute
	  is ignored when AutoCommit is turned off, and when AutoCommit is
	  turned off, DBD::mysql will not automatically reconnect to the
	  server.

in the DBD::mysql manpage, wouldn't this solve your problem?

-- Mike

Mike Schilli
m...@pe...

> Anyway, I think I've got it figured out now -- but if anyone sees
> problems with it, please let me know.
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Robert Jacobson               ..........................
> Flight Ops. Team        Solar Dynamics Observatory (SDO)
> .............                             ..............
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

Re: [log4perl-devel] catching 3rd party warns/dies?

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

On Tue, 2 Jan 2007, Lev Lvovsky wrote:

> Is there any way other than an eval block to catch 3rd party warns/
> dies/log statements via log4perl?

The FAQ shows a solution with __DIE__ and __WARN__ pseudo signal
handlers:

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

Does that help?

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] DateFormat day-of-year format bug

[Robert J. <yad...@sn...>]

Nothing like a new year to find bugs!  There is a bug in 
DateFormat.pm -- it does not print leading zeroes.  Also, it is 
formatted as a string instead of a number.

Test program:
         use Log::Log4perl::DateFormat;
         my $format = Log::Log4perl::DateFormat->new("yyyy-DDD-HH:mm:ss");
         my $time = time();
        print $format->format($time), "\n";

=> 2007-  5-09:38:44

patch:

@@ -192,7 +192,7 @@
  ######################
      } elsif($first eq "D") {
          push @{$self->{stack}}, [7, sub { $_[0] + 1}];
-        return "%${len}s";
+        return "%0" . $len . "d";

  ######################
  #a - am/pm marker    #


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Jacobson               ..........................
Flight Ops. Team        Solar Dynamics Observatory (SDO)
.............                             ..............

Re: [log4perl-devel] Revisit of database logging when database connection fails

[Robert J. <yad...@sn...>]

LOL!  I always do this -- when I've explained the problem to someone 
else, I figure it out myself soon after!

My DBI_wrapper.pm is mimicking Appender::DBI already, in that it does 
_init() (connects to the database) on new() and calls 
Appender::DBI::log() to log the message.

I can change my new() to *not* call _init(); instead, I call _init() 
right before Appender::DBI::log(), then I disconnect.

Anyway, I think I've got it figured out now -- but if anyone sees 
problems with it, please let me know.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Jacobson               ..........................
Flight Ops. Team        Solar Dynamics Observatory (SDO)
.............                             ..............

[log4perl-devel] Revisit of database logging when database connection fails

[Robert J. <yad...@sn...>]

Way back around 9/26/2006, I posted a question (Subject: question regarding logging to databases), which, thanks to Mike Schilli and John ORourke, I was able to get working.  In summary, basically I needed Appender::DBI to cache log messages when the database is not working -- I implemented a wrapper module (DBI_wrapper.pm -- code below) to do it.

However, today it seems my wrapper failed to notice the connection failure in one case, even though it seemed to work fine for all the other times.  Basically what is happening is that the database server (mysql) is closing the connection server-side because no data had been sent for a long period of time.  My program doesn't recognize that the handle is now invalid until it tries to log a message.

As I said, most of the time it seemed to reconnect fine, but in one case, I got the error:

	Log4perl: DBI appender failed to reconnect to database after 1 attempt to DBI_wrapper.pm line 134

This error did not appear for any of the previous stale database connections.  In this case, my perl program exited due to this failure.

For this program, log messages are usually hours apart and stale connections are going to happen a lot.  I'm open to other ideas, but I was thinking that I should change the appender so that it connects, writes the message, and disconnects immediately.

So what do you think?  If that's the right way to go -- is there an easy way I can wrap the existing log() method in Appender::DBI to do the connect/disconnect (including, I guess, not doing _init() on new()?

Thanks for your time,
Rob


---- DBI_wrapper.pm
package DBI_wrapper;

use warnings;
use strict;

use Carp;
use DBI;
use Data::Dumper;

require Log::Log4perl::Appender::DBI;

sub new {
	my ($class, %options) = @_;

	my $appender = Log::Log4perl::Appender::DBI->new(
		map { $_ => $options{$_} } keys %options,
	);

	my $self = {
		appender => $appender,
		name => $options{name},
		BUFFERSIZE => 2000,
		connected => 0,
		};

	if (exists $options{BUFFERSIZE}) {
		$self->{BUFFERSIZE} = $options{BUFFERSIZE};
	}
	#print "buffersize is " , $self->{BUFFERSIZE} . $self->{name} . "\n";

	bless $self, $class;
	$self->_init(%options);

	return $self;

}

sub log {
	my ($self, %p) = @_;

	# Check for DB connection
	if (! $self->{dbh}->ping() ) {
		if ($self->{connected}) {
			# Notify FOT
			$self->_notify(%p);
			my %dupe = %p;
			$dupe{message} = "Database connection went down at " . scalar gmtime;
			$dupe{log4p_level} = 'ERROR';
			# This is required to store the original time of the message
			$dupe{log4p_logtime} = $self->{appender}->{'bind_value_layouts'}{'1'}{'time_function'}->() if exists $self->{appender}->{'bind_value_layouts'}{'1'}{'time_function'};
			$self->buffer(\%dupe);
		}

		# Buffer the message
		# This is required to store the original time of the message
		$p{log4p_logtime} = $self->{appender}->{'bind_value_layouts'}{'1'}{'time_function'}->() if exists $self->{appender}->{'bind_value_layouts'}{'1'}{'time_function'};
		$self->buffer(\%p);

		# Try to reconnect
		eval {
			$self->{dbh} = $self->{connect}->();
		};
		$self->{connected} = 0;
		return 1;
	} else {
		if (not $self->{connected} ) {
			my %dupe = %p;
			$dupe{message} = "Database connection came back up at " . scalar gmtime;
			$dupe{log4p_level} = 'ERROR'; # Not an ERROR but we want attention on this
			# This is required to store the original time of the message
			$dupe{log4p_logtime} = $self->{appender}->{'bind_value_layouts'}{'1'}{'time_function'}->() if exists $self->{appender}->{'bind_value_layouts'}{'1'}{'time_function'};
			$self->buffer(\%dupe);
		}
		$self->{connected_time} = scalar gmtime();
		$self->{connected} = 1;
	}

	$self->check_buffer();

	$Log::Log4perl::caller_depth++;

	$self->{appender}->log(
		%p,
		);

	$Log::Log4perl::caller_depth--;
	return 1;
}

sub _init {
	my $self = shift;
	my %params = @_;

    if ($params{dbh}) {
        $self->{dbh} = $params{dbh};
    } else {
        $self->{connect} = sub {
            DBI->connect(@params{qw(datasource username password)},
                         {PrintError => 0})
                            or croak "Log4perl: $DBI::errstr";
        };
        $self->{dbh} = $self->{connect}->();
		$self->{connected} = 1;
        $self->{_mine} = 1;
    }
}

sub _notify {
	my $self = shift;
	my %params = @_;

	# eventually send an email or something
	# for now just print a message
	print "Database is down\n";

}

sub check_buffer {
	my $self = shift;

	return unless ($self->{BUFFER} && ref $self->{BUFFER} eq 'ARRAY');

	while ( @{$self->{BUFFER}} ) {
		my $ref = shift @{$self->{BUFFER}};
		#print Dumper %$ref;
		$Log::Log4perl::caller_depth += 2;

		# Use the original time
		local $self->{appender}->{'bind_value_layouts'}{'1'}{'time_function'}; 
		$self->{appender}->{'bind_value_layouts'}{'1'}{'time_function'} = 
			sub { $ref->{log4p_logtime} };

		$self->{appender}->log(
			%$ref,
			);
		$Log::Log4perl::caller_depth -= 2;
	}

	return 1;
}

sub buffer {
	my $self = shift;
	my $hashref = shift;

	if (defined @{$self->{BUFFER}} && (scalar @{$self->{BUFFER}} > $self->{BUFFERSIZE}) ) {
		# drop oldest message
		print "BUFFER EXCEEDED!\n";
		shift @{$self->{BUFFER}};
	} else {
		push @{$self->{BUFFER}}, $hashref;
	}
}

1;
---- End DBI_wrapper.pm

[log4perl-devel] catching 3rd party warns/dies?

[Lev L. <li...@so...>]

Hello,

Is there any way other than an eval block to catch 3rd party warns/ 
dies/log statements via log4perl?

thanks!
-lev

[log4perl-devel] Does $Log::Log4perl::caller_depth work with logdie?

[Adrian I. <adr...@ho...>]

Hi,

As far as I can tell it doesn't. I use Log4Perl via a wrapper and have found 
that my logdies are reported as occurring in my wrapper rather than in the 
code calling the wrapper. This is despite my setting 
$Log::Log4perl::caller_depth = 1 in the package defining my wrapper.

The first reason I think the problem lies in the Log4Perl code and not my 
own is that I searched for caller_depth in the Log4Perl code and while there 
are a number of places it's changed, it only seems to be used in the 
Log::Log4perl::Layout::PatternLayout::render subroutine which isn't involved 
in the implementation of logdie.

After some further investigation I think the problem is in the 
Log4Perl::Logger module. In particular the callerline subroutine. I've 
attached a diff for Logger.pm that fixes the problem which works as follows:
i) Keep stepping up the call-stack until you've reached caller_depth steps 
out of the current file.
ii) Don't evaluate the call stack if it's not needed for the message
iii) Avoid a uninitialized warning from the 'at $file line $line' in the 
case where the caller_depth has been set too large.

Points (ii) and (iii) don't actually fix the problem at hand but, in my 
opinion, do improve things slightly . Potentially (iii) could be implemented 
better (i.e. print a warning about caller_depth being wrong, allowing the 
thread id to be added to the message even if we've failed with $file etc) 
but that's up to you :o)

Cheers,
Adrian

NB I'm using 'Log-Log4perl' version 1.05 in ActivePerl 5.8.4.810. I know 
1.08 is available but I'm using Windows XP and 1.05 is the latest available 
via ppm.
NNB I had a look at the release notes between 1.05 and 1.08 and couldn't see 
any mention of something fixing this problem . 

Re: [log4perl-devel] Using Carp::Asert With Log4Perl

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

On Fri, 22 Dec 2006, Tom Purl wrote:

> Perl version: 5.8.8
> log4perl version: 1.02
> Carp::Assert version: 0.18
> I'm trying to use both the Carp::Assert and Log4Perl libraries in the
> same Perl script.  Here's how I'm using them:
>
>     use warnings;
>     use strict;
>     use Carp;
>     use Carp::Assert;
>     use Log::Log4perl qw(:easy);

The problem is that both Log::Log4perl (in :easy mode) and
Carp::Assert (by default) are trying to smuggle the symbol
'DEBUG' into the namespace of the active package.

To disambiguate Log4perl's DEBUG and Carp::Assert's DEBUG, let's
rename Carp::Assert's DEBUG to 'ADEBUG':

    BEGIN {
        use Carp::Assert;   # or:  no Carp::Assert;
        *ADEBUG = *DEBUG;
        undef *DEBUG;
    };

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

    DEBUG "foo";
    print "bar\n" if ADEBUG;

-- Mike

Mike Schilli
m...@pe...

> I tried to fix this by changing the following line:
>
>     assert($foo) if DEBUG;
>
> to this:
>
>     assert($foo) if Carp::Assert::DEBUG;

> ...but I got the same error.
>
> Does anyone know of a way I can fix this?  I would really like to be
> able to use Log4Perl *and* assertions in my script.
>
> Thanks again!
>
> Tom Purl
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

[log4perl-devel] Using Carp::Asert With Log4Perl

[Tom P. <to...@to...>]

Perl version: 5.8.8
log4perl version: 1.02
Carp::Assert version: 0.18

I'm trying to use both the Carp::Assert and Log4Perl libraries in the
same Perl script.  Here's how I'm using them:

    use warnings;
    use strict;
    use Carp;
    use Carp::Assert;
    use Log::Log4perl qw(:easy);
    Log::Log4perl->easy_init($DEBUG);


    sub main() {
        my $logger = get_logger();
        $logger->info("Starting $0...");

        my $foo = "This is a test";
        assert($foo) if DEBUG;
    }

When I try to compile this, I get the following errors:

    /usr/lib/perl5/vendor_perl/5.8.8/Log/Log4perl.pm|131| Constant
subroutine main::DEBUG redefined
    /usr/lib/perl5/vendor_perl/5.8.8/Log/Log4perl.pm|131| Prototype
mismatch: sub main::DEBUG () vs none

I tried to fix this by changing the following line:

    assert($foo) if DEBUG;

to this:

    assert($foo) if Carp::Assert::DEBUG;

...but I got the same error.

Does anyone know of a way I can fix this?  I would really like to be
able to use Log4Perl *and* assertions in my script.

Thanks again!

Tom Purl

Re: [log4perl-devel] Logging from warn() and die(), but not during an eval {}

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

On Tue, 5 Dec 2006, J. David Blackstone wrote:

>   Turns out there's an even easier way to do that. $^S can be
>   checked to see if code is in an eval. Thinking through this
>   yesterday afternoon I finally decided this wasn't a Log4perl
>   issue, but a general Perl issue, because really I think you'd
>   almost never want those SIG handlers to fire when you're in
>   an eval, trying to trap things before they become warnings
>   and errors. So I asked at use Perl; , and somebody pointed me
>   to that variable.

Nice!

>   Since I wound up not using those handlers yesterday, it was a
>   little too late, but I do still have a module called by this
>   program and by others, and I'll have to either instrument it
>   as I did the main program, or go back and use the handlers.
>   (I'm thinking about doing both, for good measure.)

Yeah, always a good idea :).

>   Looks to me like the FAQ might want to change the text of
>   those signal handlers to include a check of $^S to decide
>   whether to log or not. And somebody might like to package it
>   all up in a module, which is what I was trying to do
>   yesterday. :)

Added it in 1.09, thanks!

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] Timezone in log messages

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

On Thu, 7 Dec 2006, J. David Blackstone wrote:

>   And as a bonus, I figured out how to cheat and set this in my configuration file:
>
> log4perl.DateFormat.GMTIME = sub { $Log::Log4perl::DateFormat::GMTIME = 1 }

Unbelievable :).

>   That's probably an abuse of the configuration file sub notation, using a side effect instead of returning a value, but it works. :)  And somehow I think I might have to fight a small political battle to explicitly set a program to log in UTC rather than local time zone, but I don't think anyone will notice or care if it's done in that config file. :)  (Which is why I worked so hard to figure out how to make Oracle insert its timestamps in UTC for me.)

Logging in UTC makes a lot of sense, especially if you're running
servers in multiple time zones and need to consolidate the logs later
on.

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] Timezone in log messages

[J. D. B. <jd...@go...>]

On December 7, 2006, J. David Blackstone wrote:

> On December 7, 2006, Mike Schilli wrote:
>=20
> > There's an undocumented feature:
> >=20
> >     $Log::Log4perl::DateFormat::GMTIME =3D 1;
> >=20
> > will use UTC instead of local time.
>=20
>   Thanks, Mike!  That's just what I was looking for!

  And as a bonus, I figured out how to cheat and set this in my configurati=
on file:

log4perl.DateFormat.GMTIME =3D sub { $Log::Log4perl::DateFormat::GMTIME =3D=
 1 }

  That's probably an abuse of the configuration file sub notation, using a =
side effect instead of returning a value, but it works. :)  And somehow I t=
hink I might have to fight a small political battle to explicitly set a pro=
gram to log in UTC rather than local time zone, but I don't think anyone wi=
ll notice or care if it's done in that config file. :)  (Which is why I wor=
ked so hard to figure out how to make Oracle insert its timestamps in UTC f=
or me.)

jdb

Re: [log4perl-devel] Timezone in log messages

[J. D. B. <jd...@go...>]

On December 7, 2006, Mike Schilli wrote:

> On Tue, 5 Dec 2006, J. David Blackstone wrote:
>=20
> >   I'd like all of my log messages to report with a UTC timezone, but I =
don't want to change the timezone for the whole job.  Is there a way to spe=
cify the timezone you want in the layout?
>=20
> There's an undocumented feature:
>=20
>     $Log::Log4perl::DateFormat::GMTIME =3D 1;
>=20
> will use UTC instead of local time.

  Thanks, Mike!  That's just what I was looking for!

jdb

Re: [log4perl-devel] Timezone in log messages

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

On Tue, 5 Dec 2006, J. David Blackstone wrote:

>   I'd like all of my log messages to report with a UTC timezone, but I don't want to change the timezone for the whole job.  Is there a way to specify the timezone you want in the layout?

There's an undocumented feature:

    $Log::Log4perl::DateFormat::GMTIME = 1;

will use UTC instead of local time.

-- Mike

Mike Schilli
m...@pe...

>
>   FYI, Oracle makes it well-night impossible to generate a value of type TIMESTAMP WITH TIME ZONE for the current time but in UTC, unless you are running either the client process or the server in UTC.  Eventually I found out the way to do it was
>
> FROM_TZ(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP), '00:00')
>
>   (So my Log::Log4perl::Appender::DBI appender gets everything in the timezone I want, but I get pot luck with Log::Log4perl::Appender::File and Log::Log4perl::Appender::Screen :) )
>
> jdb
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

[log4perl-devel] Timezone in log messages

[J. D. B. <jd...@go...>]

  I'd like all of my log messages to report with a UTC timezone, but I don'=
t want to change the timezone for the whole job.  Is there a way to specify=
 the timezone you want in the layout?

  FYI, Oracle makes it well-night impossible to generate a value of type TI=
MESTAMP WITH TIME ZONE for the current time but in UTC, unless you are runn=
ing either the client process or the server in UTC.  Eventually I found out=
 the way to do it was

FROM_TZ(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP), '00:00')

  (So my Log::Log4perl::Appender::DBI appender gets everything in the timez=
one I want, but I get pot luck with Log::Log4perl::Appender::File and Log::=
Log4perl::Appender::Screen :) )

jdb

Re: [log4perl-devel] Logging from warn() and die(), but not during an eval {}

[J. D. B. <jd...@go...>]

On December 4, 2006, Mike Schilli wrote:

> >   wrapped, the exception that I wanted to ignore is now getting
> >   logged. I don't want that. I want it to be completely silent.
> >   (Failing that, I'd like to log it at a very low level.)
>=20
> Hmm, but if you want it to be completely silent, why aren't you simply
> resetting those handlers and then putting them back in place afterwards?
>=20
>     eval {
>         local $SIG{__WARN__} =3D 'IGNORE';
>         local $SIG{__DIE__}  =3D 'IGNORE';
>         # ... your code
>     };

  This doesn't help in the event that the eval is in a module I installed o=
ff of CPAN, which I can't practically modify to add that to the eval block.=
  (I could modify it, but it'd be wiped out at the next update, leading to =
a maintenance nightmare.)

  In this case I was dealing with evals in both places: my code, and a modu=
le.  I tried using local and setting the handler to 'DEFAULT', which seemed=
 to lead to more complex issues, and before I could fully trace through and=
 find out what was going on I found out about the eval in the module and de=
cided this was an untenable situation to try to fix.  So I gave up trying t=
o do a quick-and-dirty instrumentation of my code by using these handlers, =
and instrumented my code more directly.  Which is probably a good thing, al=
l in all.

> Alternatively, you could check if you're inside an eval{} (at some
> sublevel) by using code like
>=20
>     sub burried_in_eval {
>       my $i;
>=20
>       while(my ($pack, $file, $line, $sub) =3D caller($i++)) {
>          return 1 if $sub eq "(eval)";
>       }
>=20
>       return 0;
>     }
>=20
> and act accordingly in your sig handlers.

  Turns out there's an even easier way to do that.  $^S can be checked to s=
ee if code is in an eval.  Thinking through this yesterday afternoon I fina=
lly decided this wasn't a Log4perl issue, but a general Perl issue, because=
 really I think you'd almost never want those SIG handlers to fire when you=
're in an eval, trying to trap things before they become warnings and error=
s.  So I asked at use Perl; , and somebody pointed me to that variable.

  Since I wound up not using those handlers yesterday, it was a little too =
late, but I do still have a module called by this program and by others, an=
d I'll have to either instrument it as I did the main program, or go back a=
nd use the handlers.  (I'm thinking about doing both, for good measure.)

  Looks to me like the FAQ might want to change the text of those signal ha=
ndlers to include a check of $^S to decide whether to log or not.  And some=
body might like to package it all up in a module, which is what I was tryin=
g to do yesterday. :)

Thanks,
jdb

Re: [log4perl-devel] Logging from warn() and die(), but not during an eval {}

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

On Mon, 4 Dec 2006, J. David Blackstone wrote:

>   I'm trying to do a minimal setup of Log::Log4perl for an
>   existing application. I've setup my __WARN__ and __DIE__
>   signal handlers to wrap warn() and die(), but I'm running
>   into a problem. A portion of my code expects to do the
>   following:
>
> eval { ... };
> if ($@)
> {
>   return if $@ =~ m/particular error to ignore/;
>   die $@;
> }

When you say you've setup your __WARN__ and __DIE__ handlers, I assume
you've set them up according to

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

in order to have Log4perl catch and log these events.

>   In other words, I execute a piece of code that I expect may
>   throw a particular type of exception. If that exception
>   occurs, I don't want to hear about it. I just want to ignore
>   it and go on to the next step. However, if and only if some
>   other situation occurs, I want the code to die.
>
>   The problem is that now that __WARN__ and __DIE__ are
>   wrapped, the exception that I wanted to ignore is now getting
>   logged. I don't want that. I want it to be completely silent.
>   (Failing that, I'd like to log it at a very low level.)

Hmm, but if you want it to be completely silent, why aren't you simply
resetting those handlers and then putting them back in place afterwards?

    eval {
        local $SIG{__WARN__} = 'IGNORE';
        local $SIG{__DIE__}  = 'IGNORE';
        # ... your code
    };

should automatically reset them after the eval block has been processed.

Alternatively, you could check if you're inside an eval{} (at some
sublevel) by using code like

    sub burried_in_eval {
      my $i;

      while(my ($pack, $file, $line, $sub) = caller($i++)) {
         return 1 if $sub eq "(eval)";
      }

      return 0;
    }

and act accordingly in your sig handlers.

-- Mike

Mike Schilli
m...@pe...

>
> jdb
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

[log4perl-devel] Logging from warn() and die(), but not during an eval {}

[J. D. B. <jd...@go...>]

  I'm trying to do a minimal setup of Log::Log4perl for an existing applica=
tion.  I've setup my __WARN__ and __DIE__ signal handlers to wrap warn() an=
d die(), but I'm running into a problem.  A portion of my code expects to d=
o the following:

eval { ... };
if ($@)
{
  return if $@ =3D~ m/particular error to ignore/;
  die $@;
}

  In other words, I execute a piece of code that I expect may throw a parti=
cular type of exception.  If that exception occurs, I don't want to hear ab=
out it.  I just want to ignore it and go on to the next step.  However, if =
and only if some other situation occurs, I want the code to die.

  The problem is that now that __WARN__ and __DIE__ are wrapped, the except=
ion that I wanted to ignore is now getting logged.  I don't want that.  I w=
ant it to be completely silent.  (Failing that, I'd like to log it at a ver=
y low level.)

  Basically, I'm wanting Log::Log4perl to read my mind and realize that sin=
ce I eval'ed the code, I don't want anything to get logged.  Can this be ac=
complished in some way?  Failing that, what is the recommendation for how I=
 should handle this?  I'd rather not customize the %SIG handlers to deal wi=
th particular messages ... I may have a situation where I want particular m=
essages ignored if they occur in an eval, but not if they occur in regular =
code.  Is there a way to accomplish this?

jdb

Re: [log4perl-devel] Design question: Why doesn't Log::Log4Perl descend from Class::Singleton?

[Craig M. <C.M...@of...>]

Hi Rolf,

> -----Original Message-----
> From: log...@li... =
[mailto:log4perl-devel-
> bo...@li...] On Behalf Of Rolf Schaufelberger
> Sent: Wednesday, November 29, 2006 10:42 AM
> To: Mike Schilli
> Cc: log...@li...
> Subject: Re: [log4perl-devel]Design question: Why doesn't =
Log::Log4Perl descend from
> Class::Singleton?
>=20
> Hi,
>=20
> Am Mittwoch 29 November 2006 07:26 schrieb Mike Schilli:
> > On Mon, 27 Nov 2006, Rolf Schaufelberger wrote:
> > > I'm having this situation too and got problems when i tried to use
> > > init_once. The problem may arise by the fact,  that  all of my
> > > VirtualHosts have a quite similar setup, just the  filenames for =
the
> > > lofiles are different, the names for the loggers themself are the =
same
> > > since they use the same librarys and most logger names are derived =
from
> > > the library names and the root_loggers name is identical. So  I =
have to
> > > call init() with every request, which may be not the best choice =
for best
> > > performance.
> >
> > Right.
> >
> > In the current implementation, regardless if you call init() or
> > init_once(), there's only *one* configuration. The difference is =
just that
> > init() will overwrite a previous configuration, while init_once() =
will
> > ignore subsequent calls to init_once().
> >
> > Looks like what you need is support for multiple logger =
repositories:
> Yes!
> >
> >     http://wiki.apache.org/logging-log4j/AppContainerLogging
> Yes, looks like the same problem.
> >
> > which I think we need to address soon in Log4perl.
> I agree.
> >
> > But just for the sake of my understanding ... can you please explain =
the
> > name conflicts in more detail? Some example code and warning/error =
message
> > would be great.
>=20
> I would'nt call it name conflicts.  My situation looks like the =
following:
> I have several applications running on the same machine. All apps are =
more or
> less custom specific variations, they even use the same database and =
of
> course the same  perl modules. The  differences between my apps is
> maintained by a single  MyApp/<Site>/Param.pm file, which holds =
filenames,
> database connections, etc.  Each VirtualHost has its own setup in =
http.conf
> and has its own mod_perl (MasonX::WebApp) handler. This handler =
initializes
> an "application object which is a subclass  from =
Apache::Singleton::Request
> by passing the name of the site to the instance-method.  In the next =
step
> Log4perl is "init()"ed , the name for the .conf file is recieved from =
the
> application object which gets from the Param.pm.
> Earlier i tried to setup Log4perl with init_once in the mod_perl =
handler init
> phase during apache startup, since all the information I need is known =
at
> that time. Yet, as you write, since the loggers are kept in a global
> namespace all logs where written to the logfiles of the first handler =
calling
> init_once.
> There are no error messages or that, it just doesn't  do what I would =
like it
> to do.
>=20
> The solution would be to allow passing a namespace-parameter to the =
init_once
> method and make get_logger find the right namespace.
>=20
> I have some similar problems with Locale::Maketext which just uses =
caller() to
> get the callers namespace and inserts it's data to that namespace. =
Yet, my
> app uses a common module to make that initialisation and thus the =
namespace
> would be identical for all callers. I have :
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> package MyApp::I18N;
> sub do_init {
>  # do Locale::Maketet::Lexion setup here
>   L::M::L->setup (...)
>   ..}
> 1;
>=20
> MyApp::<Site:>::I18N;
> use base MyApp::I18N;
> 1;
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Now when I call MyApp::<Site>::I18N->do_init
> in L::M::L::setup caller() gives you MyApp::I18N
> (which I would consider as a perl bug)
> So I had to copy (!) the do_init method to each subclass and call
> L::M::L-> setup from there.


That shouldn't be a problem at all using the singleton class approach =
because there's nothing stopping you from passing class names around =
instead of initialization namespace strings in your example. Effectively =
it comes down to the same thing there. I think it's a matter of taste if =
the designers prefer to use classes to distinguish between Log::Log4Perl =
instances or to use strings (passed to init() or init_once()) and =
internal global hashes to store what's now global. The result is the =
same, but personally I prefer the first approach because:
	1. an app won't compile if it uses the wrong class name, whereas when =
using strings it will, and it will run making typos harder to find.
	2. more legible design (but that's really just a matter of taste).
Using optional strings defining the namespace (passed to init() or =
init_once()) on the other hand will make it all more backwards =
compatible in usage.

=20
> I think the name_space problem with mod_perl is something general and =
probably
> should be solved there. Using an individual perl instance for each =
VirtHost
> has the big disadvantage, that my apaches processes become very very =
fat and
> I have no benefit in saving memory by preloading all my needed =
modules.
> So a "use namspace 'MyNamespace" would be fine, but  that's just a =
"wish", not
> a solution I've been thinking about in depth :-)

Uhh I don't quiet get this. I think there is a misunderstanding because =
I didn't imply that it's a requirement to use an individual perl =
instance for each VirtHost or something like that... it's complete =
unrelated, so it's safe to forget about. Besides no matter which of the =
2 approaches is chosen to solve the globals problem, the memory =
consumption will be equivalent and quite minor, so that's not something =
to worry about either.

>=20
> >
> > -- Mike
> >
> > Mike Schilli
> > m...@pe...
> >
> > > Yet i use Class:Singleton too in my apps, but setup as subclass
> > > Apache::Singleton::Request, and so  using it would make no =
difference at
> > > all. I can't use Apache::Singleon::Process  because some other =
modules
> > > are using caller() to stick some functionality to the callers =
namespace
> > > which doesn't work for me properly.
> > >
> > > But as you told that you have running several Virt.Hosts and ARE =
using
> > > init_once, how do you avoid naming conflicts ? is it sufficient =
just to
> > > give the root logger another name ?
> > >
> > > > > I think a better design would be to make Log::Log4Perl descend =
from
> > > > > Class::Singleton, store all variables that are now globals in =
the
> > > > > instance, and let users optionally create subclassed versions =
of
> > > > > Log::Log4Perl in there own namespaces.
> > > >
> > > > Interesting idea. However, I'm not sure how that would be =
different
> > > > than the situation we have now. Currently we insist that init() =
gets
> > > > called exactly once and the entire Log4perl configuration is set =
up
> > > > for all apps that will be running within a process.
> > > >
> > > > We don't have a way to run several L4p universes within the same
> > > > process with their own configuration. That would be useful, but =
that
> > > > wouldn't work with Class::Singleton, which essentially shares =
one,
> > > > right?
> > > >
> > > > Maybe you could send more details about the application =
framework
> > > > you're working on, I'd be interested to see how we can make =
Log4perl
> > > > fit its requirements.
> > > >
> > > > -- Mike
> > > >
> > > > Mike Schilli
> > > > m...@pe...
> > > >
> > > > > E.g. you'ld get something like this:
> > > > >
> > > > >
> > > > >
> > > > > package AppX;
> > > > >
> > > > > use AppX::Log4Perl; # descends from Log::Log4Perl
> > > > >
> > > > > ...
> > > > >
> > > > > my $l4p =3D AppX::Log4Perl->instance();
> > > > >
> > > > > $l4p->init_once('appx.conf');
> > > > >
> > > > > my $logger =3D $l4p->get_logger();
> > > > >
> > > > >
> > > > >
> > > > > .... then in another application sharing the same httpd:
> > > > >
> > > > > package AppY;
> > > > >
> > > > > use AppY::Log4Perl; # descends from Log::Log4Perl
> > > > >
> > > > > ...
> > > > >
> > > > > $l4p->init_once('appy.conf');
> > > > >
> > > > > my $logger =3D $l4p->get_logger();
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ... and AppX::Log4Perl will look like exactly like this:
> > > > >
> > > > >
> > > > >
> > > > > package AppX::Log4Perl;
> > > > >
> > > > > use strict;
> > > > >
> > > > > use base(Log::Log4Perl);
> > > > >
> > > > > 1;
> > > > >
> > > > > __END__
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I know it will be a major change to build this into =
Log::Log4Perl but
> > > > > I think it can be done while retaining backwards =
compatibility.
> > > > >
> > > > > All current class methods now can be automatically turned into =
both
> > > > > class and object methods at the same time like this:
> > > > >
> > > > > sub a_class_method {
> > > > >
> > > > >  my $proto =3D shift;
> > > > >
> > > > >  my $self =3D ref($proto)  ? $proto : $proto->instance();
> > > > >
> > > > >  }
> > > > >
> > > > > Actually the magic above can become more involved if =
necessary.
> > > > >
> > > > >
> > > > >
> > > > > Log::Log4Perl is a great piece of work.... I only miss that.
> > > > >
> > > > >
> > > > >
> > > > > In general when making packages, one must really scratch one's =
head a
> > > > > few times if deciding to use globals, because they are almost =
always
> > > > > unnecessary (except for constants) and a simple object or else
> > > > > Class::Singleton based alternative is almost always the =
solution.
> > > > >
> > > > >
> > > > >
> > > > > That's just my 2p.
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Craig Manley.
> > > >
> > > > =
-----------------------------------------------------------------------
> > > >-- Take Surveys. Earn Cash. Influence the Future of IT
> > > > Join SourceForge.net's Techsay panel and you'll get the chance =
to share
> > > > your opinions on IT & business topics through brief surveys - =
and earn
> > > > cash
> > > > =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVD
> > > >EV _______________________________________________
> > > > log4perl-devel mailing list
> > > > log...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/log4perl-devel
> > >
> > > --
> > > Rolf Schaufelberger
> > > rs...@pl...
> > >
> > >
> > > =
-------------------------------------------------------------------------=

> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to =
share
> > > your opinions on IT & business topics through brief surveys - and =
earn
> > > cash
> > > =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> > > _______________________________________________
> > > log4perl-devel mailing list
> > > log...@li...
> > > https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>=20
> --
> Mit freundlichen Gr=FC=DFen
> Rolf Schaufelberger
>=20
>=20
> plusW
> Rolf Schaufelberger
> Beim Br=FCnnele 6        Tel. 49 7181 994 35 50
> 73614 Schorndorf       Fax. 49 7181 994 32 75
> rs...@pl...
>=20
>=20
> =
-------------------------------------------------------------------------=

> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =
share your
> opinions on IT & business topics through brief surveys - and earn cash
> =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
> --
> Deze email is gecontroleerd door CAIWAY Internet Virusvrij.
> Voor meer informatie, zie http://www.caiway.nl/

-Craig Manley

Re: [log4perl-devel] =?iso-8859-1?q?Design_question=3A_Why_doesn=27t_?= =?iso-8859-1?q?Log=3A=3ALog4Perl_descend=09from_Class=3A=3ASingleton=3F?=

[Rolf S. <rs...@pl...>]

Hi,=20

Am Mittwoch 29 November 2006 07:26 schrieb Mike Schilli:
> On Mon, 27 Nov 2006, Rolf Schaufelberger wrote:
> > I'm having this situation too and got problems when i tried to use
> > init_once. The problem may arise by the fact,  that  all of my
> > VirtualHosts have a quite similar setup, just the  filenames for the
> > lofiles are different, the names for the loggers themself are the same
> > since they use the same librarys and most logger names are derived from
> > the library names and the root_loggers name is identical. So  I have to
> > call init() with every request, which may be not the best choice for be=
st
> > performance.
>
> Right.
>
> In the current implementation, regardless if you call init() or
> init_once(), there's only *one* configuration. The difference is just that
> init() will overwrite a previous configuration, while init_once() will
> ignore subsequent calls to init_once().
>
> Looks like what you need is support for multiple logger repositories:
Yes!
>
>     http://wiki.apache.org/logging-log4j/AppContainerLogging
Yes, looks like the same problem.
>
> which I think we need to address soon in Log4perl.
I agree.
>
> But just for the sake of my understanding ... can you please explain the
> name conflicts in more detail? Some example code and warning/error message
> would be great.

I would'nt call it name conflicts.  My situation looks like the following:
I have several applications running on the same machine. All apps are more =
or=20
less custom specific variations, they even use the same database and of=20
course the same  perl modules. The  differences between my apps is =20
maintained by a single  MyApp/<Site>/Param.pm file, which holds filenames,=
=20
database connections, etc.  Each VirtualHost has its own setup in http.conf=
=20
and has its own mod_perl (MasonX::WebApp) handler. This handler initializes=
=20
an "application object which is a subclass  from Apache::Singleton::Request=
 =20
by passing the name of the site to the instance-method.  In the next step=20
Log4perl is "init()"ed , the name for the .conf file is recieved from the=20
application object which gets from the Param.pm.=20
Earlier i tried to setup Log4perl with init_once in the mod_perl handler in=
it=20
phase during apache startup, since all the information I need is known at=20
that time. Yet, as you write, since the loggers are kept in a global=20
namespace all logs where written to the logfiles of the first handler calli=
ng=20
init_once.=20
There are no error messages or that, it just doesn't  do what I would like =
it=20
to do.

The solution would be to allow passing a namespace-parameter to the init_on=
ce=20
method and make get_logger find the right namespace.

I have some similar problems with Locale::Maketext which just uses caller()=
 to=20
get the callers namespace and inserts it's data to that namespace. Yet, my=
=20
app uses a common module to make that initialisation and thus the namespace=
=20
would be identical for all callers. I have :
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
package MyApp::I18N;
sub do_init {
 # do Locale::Maketet::Lexion setup here
  L::M::L->setup (...)
  ..}
1;

MyApp::<Site:>::I18N;
use base MyApp::I18N;
1;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Now when I call MyApp::<Site>::I18N->do_init
in L::M::L::setup caller() gives you MyApp::I18N=20
(which I would consider as a perl bug)
So I had to copy (!) the do_init method to each subclass and call=20
L::M::L-> setup from there.

I think the name_space problem with mod_perl is something general and proba=
bly=20
should be solved there. Using an individual perl instance for each VirtHost=
 =20
has the big disadvantage, that my apaches processes become very very fat an=
d=20
I have no benefit in saving memory by preloading all my needed modules.=20
So a "use namspace 'MyNamespace" would be fine, but  that's just a "wish", =
not=20
a solution I've been thinking about in depth :-)

>
> -- Mike
>
> Mike Schilli
> m...@pe...
>
> > Yet i use Class:Singleton too in my apps, but setup as subclass
> > Apache::Singleton::Request, and so  using it would make no difference at
> > all. I can't use Apache::Singleon::Process  because some other modules
> > are using caller() to stick some functionality to the callers namespace
> > which doesn't work for me properly.
> >
> > But as you told that you have running several Virt.Hosts and ARE using
> > init_once, how do you avoid naming conflicts ? is it sufficient just to
> > give the root logger another name ?
> >
> > > > I think a better design would be to make Log::Log4Perl descend from
> > > > Class::Singleton, store all variables that are now globals in the
> > > > instance, and let users optionally create subclassed versions of
> > > > Log::Log4Perl in there own namespaces.
> > >
> > > Interesting idea. However, I'm not sure how that would be different
> > > than the situation we have now. Currently we insist that init() gets
> > > called exactly once and the entire Log4perl configuration is set up
> > > for all apps that will be running within a process.
> > >
> > > We don't have a way to run several L4p universes within the same
> > > process with their own configuration. That would be useful, but that
> > > wouldn't work with Class::Singleton, which essentially shares one,
> > > right?
> > >
> > > Maybe you could send more details about the application framework
> > > you're working on, I'd be interested to see how we can make Log4perl
> > > fit its requirements.
> > >
> > > -- Mike
> > >
> > > Mike Schilli
> > > m...@pe...
> > >
> > > > E.g. you'ld get something like this:
> > > >
> > > >
> > > >
> > > > package AppX;
> > > >
> > > > use AppX::Log4Perl; # descends from Log::Log4Perl
> > > >
> > > > ...
> > > >
> > > > my $l4p =3D AppX::Log4Perl->instance();
> > > >
> > > > $l4p->init_once('appx.conf');
> > > >
> > > > my $logger =3D $l4p->get_logger();
> > > >
> > > >
> > > >
> > > > .... then in another application sharing the same httpd:
> > > >
> > > > package AppY;
> > > >
> > > > use AppY::Log4Perl; # descends from Log::Log4Perl
> > > >
> > > > ...
> > > >
> > > > $l4p->init_once('appy.conf');
> > > >
> > > > my $logger =3D $l4p->get_logger();
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ... and AppX::Log4Perl will look like exactly like this:
> > > >
> > > >
> > > >
> > > > package AppX::Log4Perl;
> > > >
> > > > use strict;
> > > >
> > > > use base(Log::Log4Perl);
> > > >
> > > > 1;
> > > >
> > > > __END__
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I know it will be a major change to build this into Log::Log4Perl b=
ut
> > > > I think it can be done while retaining backwards compatibility.
> > > >
> > > > All current class methods now can be automatically turned into both
> > > > class and object methods at the same time like this:
> > > >
> > > > sub a_class_method {
> > > >
> > > >  my $proto =3D shift;
> > > >
> > > >  my $self =3D ref($proto)  ? $proto : $proto->instance();
> > > >
> > > >  }
> > > >
> > > > Actually the magic above can become more involved if necessary.
> > > >
> > > >
> > > >
> > > > Log::Log4Perl is a great piece of work.... I only miss that.
> > > >
> > > >
> > > >
> > > > In general when making packages, one must really scratch one's head=
 a
> > > > few times if deciding to use globals, because they are almost always
> > > > unnecessary (except for constants) and a simple object or else
> > > > Class::Singleton based alternative is almost always the solution.
> > > >
> > > >
> > > >
> > > > That's just my 2p.
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Craig Manley.
> > >
> > > ---------------------------------------------------------------------=
=2D-
> > >-- Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to sha=
re
> > > your opinions on IT & business topics through brief surveys - and earn
> > > cash
> > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CI=
D=3DDEVD
> > >EV _______________________________________________
> > > log4perl-devel mailing list
> > > log...@li...
> > > https://lists.sourceforge.net/lists/listinfo/log4perl-devel
> >
> > --
> > Rolf Schaufelberger
> > rs...@pl...
> >
> >
> > -----------------------------------------------------------------------=
=2D-
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys - and earn
> > cash
> > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> > _______________________________________________
> > log4perl-devel mailing list
> > log...@li...
> > https://lists.sourceforge.net/lists/listinfo/log4perl-devel

=2D-=20
Mit freundlichen Gr=FC=DFen
Rolf Schaufelberger


plusW
Rolf Schaufelberger=20
Beim Br=FCnnele 6        Tel. 49 7181 994 35 50
73614 Schorndorf       Fax. 49 7181 994 32 75
rs...@pl...

Re: [log4perl-devel] Design question: Why doesn't Log::Log4Perldescend from Class::Singleton?

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

On Mon, 27 Nov 2006, Craig Manley wrote:

> Yes, init_once() calls init() which sets the global
> $Log::Log4perl::Logger::INITIALIZED unless it's been set already. In
> mod_perl multiple applications/handlers can run in the same httpd child
> (of course not at the same time), but that means the configuration of
> the first handler that called init_once() will be the configuration that
> will persist through all other handlers called in the future in that
> same httpd child.

Correct. Looks like we need multiple logger repositories:

    http://wiki.apache.org/logging-log4j/AppContainerLogging

I'll look into your suggestion of using Class::Singleton, this
could significantly reduce the work to get rid of these nasty globals
and provide backwards compatibility for those who don't want to
deal with subclassing.

If you have more implementation ideas or (even better!) patches,
please keep'em coming :)

Thanks,

-- Mike

Mike Schilli
m...@pe...

> Side note: Depending on the mod_perl version and configuration, a single
> Perl interpreter instance is shared for every virtual host in a httpd
> child, or each virtual host can get it's own Perl interpreter instance.
> Anyhow in the best of cases, more Perl handlers/apps run can run in the
> same virtual host and share the same Perl interpreter instance and
> therefore all it's loaded modules and globals. Global variables are
> really nasty in such environments and there are more Perl modules that
> use them causing mod_perl programmers to have to localize the globals in
> those modules in order to prevent conflicts with other mod_perl apps.
>
>
> > Interesting idea. However, I'm not sure how that would be different
> > than the situation we have now. Currently we insist that init() gets
> > called exactly once and the entire Log4perl configuration is set up
> > for all apps that will be running within a process.
> >
> > We don't have a way to run several L4p universes within the same
> process
> > with their own configuration. That would be useful, but that wouldn't
> > work with Class::Singleton, which essentially shares one, right?
>
> Not exactly. There is a separate singleton instance for each child of
> Class::Singleton (and thank goodness for that otherwise that class would
> be quiet useless in practice), so if AppX::Log4Perl and AppY::Log4Perl
> both descend from Class::Singleton, then a separate singleton instance
> will exist for both of these child classes.
>
>
> > Maybe you could send more details about the application framework
> > you're working on, I'd be interested to see how we can make Log4perl
> > fit its requirements.
>
> Well you can roughly compare it to one of the existing frameworks such
> as Catalyst etc. I just need a flexible logging system to plug into it
> that doesn't have any known flaws that could get any future users of it
> stuck with weird problems.
>
> -Craig Manley
>
>
> >
> > -- Mike
> >
> > Mike Schilli
> > m...@pe...
> >
> > > E.g. you'ld get something like this:
> > >
> > >
> > >
> > > package AppX;
> > >
> > > use AppX::Log4Perl; # descends from Log::Log4Perl
> > >
> > > ...
> > >
> > > my $l4p = AppX::Log4Perl->instance();
> > >
> > > $l4p->init_once('appx.conf');
> > >
> > > my $logger = $l4p->get_logger();
> > >
> > >
> > >
> > > .... then in another application sharing the same httpd:
> > >
> > > package AppY;
> > >
> > > use AppY::Log4Perl; # descends from Log::Log4Perl
> > >
> > > ...
> > >
> > > $l4p->init_once('appy.conf');
> > >
> > > my $logger = $l4p->get_logger();
> > >
> > >
> > >
> > >
> > >
> > > ... and AppX::Log4Perl will look like exactly like this:
> > >
> > >
> > >
> > > package AppX::Log4Perl;
> > >
> > > use strict;
> > >
> > > use base(Log::Log4Perl);
> > >
> > > 1;
> > >
> > > __END__
> > >
> > >
> > >
> > >
> > >
> > > I know it will be a major change to build this into Log::Log4Perl
> but I
> > > think it can be done while retaining backwards compatibility.
> > >
> > > All current class methods now can be automatically turned into both
> > > class and object methods at the same time like this:
> > >
> > > sub a_class_method {
> > >
> > >  my $proto = shift;
> > >
> > >  my $self = ref($proto)  ? $proto : $proto->instance();
> > >
> > >  }
> > >
> > > Actually the magic above can become more involved if necessary.
> > >
> > >
> > >
> > > Log::Log4Perl is a great piece of work.... I only miss that.
> > >
> > >
> > >
> > > In general when making packages, one must really scratch one's head
> a
> > > few times if deciding to use globals, because they are almost always
> > > unnecessary (except for constants) and a simple object or else
> > > Class::Singleton based alternative is almost always the solution.
> > >
> > >
> > >
> > > That's just my 2p.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Craig Manley.
> > >
> > >
> > --
> > Deze email is gecontroleerd door CAIWAY Internet Virusvrij.
> > Voor meer informatie, zie http://www.caiway.nl/
>

Re: [log4perl-devel] =?iso-8859-1?q?Design_question=3A_Why_doesn=27t_?= =?iso-8859-1?q?Log=3A=3ALog4Perl_descend=09from_Class=3A=3ASingleton=3F?=

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

On Mon, 27 Nov 2006, Rolf Schaufelberger wrote:

> I'm having this situation too and got problems when i tried to use init_once.
> The problem may arise by the fact,  that  all of my VirtualHosts have a quite
> similar setup, just the  filenames for the lofiles are different, the names
> for the loggers themself are the same since they use the same librarys and
> most logger names are derived from the library names and the root_loggers
> name is identical. So  I have to call init() with every request, which may be
> not the best choice for best performance.

Right.

In the current implementation, regardless if you call init() or init_once(),
there's only *one* configuration. The difference is just that init() will
overwrite a previous configuration, while init_once() will ignore subsequent
calls to init_once().

Looks like what you need is support for multiple logger repositories:

    http://wiki.apache.org/logging-log4j/AppContainerLogging

which I think we need to address soon in Log4perl.

But just for the sake of my understanding ... can you please explain the
name conflicts in more detail? Some example code and warning/error message
would be great.

-- Mike

Mike Schilli
m...@pe...

> Yet i use Class:Singleton too in my apps, but setup as subclass
> Apache::Singleton::Request, and so  using it would make no difference at all.
> I can't use Apache::Singleon::Process  because some other modules are using
> caller() to stick some functionality to the callers namespace which doesn't
> work for me properly.
>
> But as you told that you have running several Virt.Hosts and ARE using
> init_once, how do you avoid naming conflicts ? is it sufficient just to give
> the root logger another name ?
>
> >
> > > I think a better design would be to make Log::Log4Perl descend from
> > > Class::Singleton, store all variables that are now globals in the
> > > instance, and let users optionally create subclassed versions of
> > > Log::Log4Perl in there own namespaces.
> >
> > Interesting idea. However, I'm not sure how that would be different
> > than the situation we have now. Currently we insist that init() gets
> > called exactly once and the entire Log4perl configuration is set up
> > for all apps that will be running within a process.
> >
> > We don't have a way to run several L4p universes within the same process
> > with their own configuration. That would be useful, but that wouldn't
> > work with Class::Singleton, which essentially shares one, right?
> >
> > Maybe you could send more details about the application framework
> > you're working on, I'd be interested to see how we can make Log4perl
> > fit its requirements.
> >
> > -- Mike
> >
> > Mike Schilli
> > m...@pe...
> >
> > > E.g. you'ld get something like this:
> > >
> > >
> > >
> > > package AppX;
> > >
> > > use AppX::Log4Perl; # descends from Log::Log4Perl
> > >
> > > ...
> > >
> > > my $l4p = AppX::Log4Perl->instance();
> > >
> > > $l4p->init_once('appx.conf');
> > >
> > > my $logger = $l4p->get_logger();
> > >
> > >
> > >
> > > .... then in another application sharing the same httpd:
> > >
> > > package AppY;
> > >
> > > use AppY::Log4Perl; # descends from Log::Log4Perl
> > >
> > > ...
> > >
> > > $l4p->init_once('appy.conf');
> > >
> > > my $logger = $l4p->get_logger();
> > >
> > >
> > >
> > >
> > >
> > > ... and AppX::Log4Perl will look like exactly like this:
> > >
> > >
> > >
> > > package AppX::Log4Perl;
> > >
> > > use strict;
> > >
> > > use base(Log::Log4Perl);
> > >
> > > 1;
> > >
> > > __END__
> > >
> > >
> > >
> > >
> > >
> > > I know it will be a major change to build this into Log::Log4Perl but I
> > > think it can be done while retaining backwards compatibility.
> > >
> > > All current class methods now can be automatically turned into both
> > > class and object methods at the same time like this:
> > >
> > > sub a_class_method {
> > >
> > >  my $proto = shift;
> > >
> > >  my $self = ref($proto)  ? $proto : $proto->instance();
> > >
> > >  }
> > >
> > > Actually the magic above can become more involved if necessary.
> > >
> > >
> > >
> > > Log::Log4Perl is a great piece of work.... I only miss that.
> > >
> > >
> > >
> > > In general when making packages, one must really scratch one's head a
> > > few times if deciding to use globals, because they are almost always
> > > unnecessary (except for constants) and a simple object or else
> > > Class::Singleton based alternative is almost always the solution.
> > >
> > >
> > >
> > > That's just my 2p.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Craig Manley.
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > log4perl-devel mailing list
> > log...@li...
> > https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>
> --
> Rolf Schaufelberger
> rs...@pl...
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>

Re: [log4perl-devel] =?iso-8859-1?q?Design_question=3A_Why_doesn=27t_?= =?iso-8859-1?q?Log=3A=3ALog4Perl_descend=09from_Class=3A=3ASinglet?= =?iso-8859-1?q?on=3F?=

[Rolf S. <rs...@pl...>]

Hi, 

Am Montag 27 November 2006 16:31 schrieb Mike Schilli:
> On Thu, 23 Nov 2006, Craig Manley wrote:
> > Looking at the Log::Log4Perl code and it's suitability to be used in an
> > application framework I'm working on, I see that it can't be used
> > (safely) in multiple applications running within the same mod_perl
> > server. This is because even though these applications use there own
> > module namespaces, they obviously will clash with each other when
> > calling the init or init_once method.
>
> Thanks for your suggestion.
>
> But are you sure? I'm running mod_perl servers with several
> applications in production, and the way to make it work is to
> call either init() at Apache startup or init_once() per
> application:
>
>     http://log4perl.sourceforge.net/d/Log/Log4perl/FAQ.html#792b4

I'm having this situation too and got problems when i tried to use init_once. 
The problem may arise by the fact,  that  all of my VirtualHosts have a quite 
similar setup, just the  filenames for the lofiles are different, the names 
for the loggers themself are the same since they use the same librarys and 
most logger names are derived from the library names and the root_loggers 
name is identical. So  I have to call init() with every request, which may be 
not the best choice for best performance. 
Yet i use Class:Singleton too in my apps, but setup as subclass 
Apache::Singleton::Request, and so  using it would make no difference at all. 
I can't use Apache::Singleon::Process  because some other modules are using 
caller() to stick some functionality to the callers namespace which doesn't 
work for me properly. 

But as you told that you have running several Virt.Hosts and ARE using 
init_once, how do you avoid naming conflicts ? is it sufficient just to give 
the root logger another name ? 

>
> > I think a better design would be to make Log::Log4Perl descend from
> > Class::Singleton, store all variables that are now globals in the
> > instance, and let users optionally create subclassed versions of
> > Log::Log4Perl in there own namespaces.
>
> Interesting idea. However, I'm not sure how that would be different
> than the situation we have now. Currently we insist that init() gets
> called exactly once and the entire Log4perl configuration is set up
> for all apps that will be running within a process.
>
> We don't have a way to run several L4p universes within the same process
> with their own configuration. That would be useful, but that wouldn't
> work with Class::Singleton, which essentially shares one, right?
>
> Maybe you could send more details about the application framework
> you're working on, I'd be interested to see how we can make Log4perl
> fit its requirements.
>
> -- Mike
>
> Mike Schilli
> m...@pe...
>
> > E.g. you'ld get something like this:
> >
> >
> >
> > package AppX;
> >
> > use AppX::Log4Perl; # descends from Log::Log4Perl
> >
> > ...
> >
> > my $l4p = AppX::Log4Perl->instance();
> >
> > $l4p->init_once('appx.conf');
> >
> > my $logger = $l4p->get_logger();
> >
> >
> >
> > .... then in another application sharing the same httpd:
> >
> > package AppY;
> >
> > use AppY::Log4Perl; # descends from Log::Log4Perl
> >
> > ...
> >
> > $l4p->init_once('appy.conf');
> >
> > my $logger = $l4p->get_logger();
> >
> >
> >
> >
> >
> > ... and AppX::Log4Perl will look like exactly like this:
> >
> >
> >
> > package AppX::Log4Perl;
> >
> > use strict;
> >
> > use base(Log::Log4Perl);
> >
> > 1;
> >
> > __END__
> >
> >
> >
> >
> >
> > I know it will be a major change to build this into Log::Log4Perl but I
> > think it can be done while retaining backwards compatibility.
> >
> > All current class methods now can be automatically turned into both
> > class and object methods at the same time like this:
> >
> > sub a_class_method {
> >
> >  my $proto = shift;
> >
> >  my $self = ref($proto)  ? $proto : $proto->instance();
> >
> >  }
> >
> > Actually the magic above can become more involved if necessary.
> >
> >
> >
> > Log::Log4Perl is a great piece of work.... I only miss that.
> >
> >
> >
> > In general when making packages, one must really scratch one's head a
> > few times if deciding to use globals, because they are almost always
> > unnecessary (except for constants) and a simple object or else
> > Class::Singleton based alternative is almost always the solution.
> >
> >
> >
> > That's just my 2p.
> >
> >
> >
> > Regards,
> >
> > Craig Manley.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel

-- 
Rolf Schaufelberger
rs...@pl...

Re: [log4perl-devel] Design question: Why doesn't Log::Log4Perldescend from Class::Singleton?

[Craig M. <C.M...@of...>]

> -----Original Message-----
> From: Mike Schilli [mailto:m...@pe...]
> Sent: Monday, November 27, 2006 4:32 PM
> To: Craig Manley
> Cc: log...@li...
> Subject: Re: [log4perl-devel] Design question: Why doesn't
Log::Log4Perldescend from
> Class::Singleton?
>=20
> On Thu, 23 Nov 2006, Craig Manley wrote:
>=20
> > Looking at the Log::Log4Perl code and it's suitability to be used in
an
> > application framework I'm working on, I see that it can't be used
> > (safely) in multiple applications running within the same mod_perl
> > server. This is because even though these applications use there own
> > module namespaces, they obviously will clash with each other when
> > calling the init or init_once method.
>=20
> Thanks for your suggestion.
>=20
> But are you sure? I'm running mod_perl servers with several
> applications in production, and the way to make it work is to
> call either init() at Apache startup or init_once() per
> application:
>=20
>     http://log4perl.sourceforge.net/d/Log/Log4perl/FAQ.html#792b4
>=20
> > I think a better design would be to make Log::Log4Perl descend from
> > Class::Singleton, store all variables that are now globals in the
> > instance, and let users optionally create subclassed versions of
> > Log::Log4Perl in there own namespaces.

Yes, init_once() calls init() which sets the global
$Log::Log4perl::Logger::INITIALIZED unless it's been set already. In
mod_perl multiple applications/handlers can run in the same httpd child
(of course not at the same time), but that means the configuration of
the first handler that called init_once() will be the configuration that
will persist through all other handlers called in the future in that
same httpd child.
Side note: Depending on the mod_perl version and configuration, a single
Perl interpreter instance is shared for every virtual host in a httpd
child, or each virtual host can get it's own Perl interpreter instance.
Anyhow in the best of cases, more Perl handlers/apps run can run in the
same virtual host and share the same Perl interpreter instance and
therefore all it's loaded modules and globals. Global variables are
really nasty in such environments and there are more Perl modules that
use them causing mod_perl programmers to have to localize the globals in
those modules in order to prevent conflicts with other mod_perl apps.


> Interesting idea. However, I'm not sure how that would be different
> than the situation we have now. Currently we insist that init() gets
> called exactly once and the entire Log4perl configuration is set up
> for all apps that will be running within a process.
>=20
> We don't have a way to run several L4p universes within the same
process
> with their own configuration. That would be useful, but that wouldn't
> work with Class::Singleton, which essentially shares one, right?

Not exactly. There is a separate singleton instance for each child of
Class::Singleton (and thank goodness for that otherwise that class would
be quiet useless in practice), so if AppX::Log4Perl and AppY::Log4Perl
both descend from Class::Singleton, then a separate singleton instance
will exist for both of these child classes.


> Maybe you could send more details about the application framework
> you're working on, I'd be interested to see how we can make Log4perl
> fit its requirements.

Well you can roughly compare it to one of the existing frameworks such
as Catalyst etc. I just need a flexible logging system to plug into it
that doesn't have any known flaws that could get any future users of it
stuck with weird problems.

-Craig Manley


>=20
> -- Mike
>=20
> Mike Schilli
> m...@pe...
>=20
> > E.g. you'ld get something like this:
> >
> >
> >
> > package AppX;
> >
> > use AppX::Log4Perl; # descends from Log::Log4Perl
> >
> > ...
> >
> > my $l4p =3D AppX::Log4Perl->instance();
> >
> > $l4p->init_once('appx.conf');
> >
> > my $logger =3D $l4p->get_logger();
> >
> >
> >
> > .... then in another application sharing the same httpd:
> >
> > package AppY;
> >
> > use AppY::Log4Perl; # descends from Log::Log4Perl
> >
> > ...
> >
> > $l4p->init_once('appy.conf');
> >
> > my $logger =3D $l4p->get_logger();
> >
> >
> >
> >
> >
> > ... and AppX::Log4Perl will look like exactly like this:
> >
> >
> >
> > package AppX::Log4Perl;
> >
> > use strict;
> >
> > use base(Log::Log4Perl);
> >
> > 1;
> >
> > __END__
> >
> >
> >
> >
> >
> > I know it will be a major change to build this into Log::Log4Perl
but I
> > think it can be done while retaining backwards compatibility.
> >
> > All current class methods now can be automatically turned into both
> > class and object methods at the same time like this:
> >
> > sub a_class_method {
> >
> >  my $proto =3D shift;
> >
> >  my $self =3D ref($proto)  ? $proto : $proto->instance();
> >
> >  }
> >
> > Actually the magic above can become more involved if necessary.
> >
> >
> >
> > Log::Log4Perl is a great piece of work.... I only miss that.
> >
> >
> >
> > In general when making packages, one must really scratch one's head
a
> > few times if deciding to use globals, because they are almost always
> > unnecessary (except for constants) and a simple object or else
> > Class::Singleton based alternative is almost always the solution.
> >
> >
> >
> > That's just my 2p.
> >
> >
> >
> > Regards,
> >
> > Craig Manley.
> >
> >
> --
> Deze email is gecontroleerd door CAIWAY Internet Virusvrij.
> Voor meer informatie, zie http://www.caiway.nl/

Re: [log4perl-devel] Design question: Why doesn't Log::Log4Perl descend from Class::Singleton?

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

On Thu, 23 Nov 2006, Craig Manley wrote:

> Looking at the Log::Log4Perl code and it's suitability to be used in an
> application framework I'm working on, I see that it can't be used
> (safely) in multiple applications running within the same mod_perl
> server. This is because even though these applications use there own
> module namespaces, they obviously will clash with each other when
> calling the init or init_once method.

Thanks for your suggestion.

But are you sure? I'm running mod_perl servers with several
applications in production, and the way to make it work is to
call either init() at Apache startup or init_once() per
application:

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

> I think a better design would be to make Log::Log4Perl descend from
> Class::Singleton, store all variables that are now globals in the
> instance, and let users optionally create subclassed versions of
> Log::Log4Perl in there own namespaces.

Interesting idea. However, I'm not sure how that would be different
than the situation we have now. Currently we insist that init() gets
called exactly once and the entire Log4perl configuration is set up
for all apps that will be running within a process.

We don't have a way to run several L4p universes within the same process
with their own configuration. That would be useful, but that wouldn't
work with Class::Singleton, which essentially shares one, right?

Maybe you could send more details about the application framework
you're working on, I'd be interested to see how we can make Log4perl
fit its requirements.

-- Mike

Mike Schilli
m...@pe...

> E.g. you'ld get something like this:
>
>
>
> package AppX;
>
> use AppX::Log4Perl; # descends from Log::Log4Perl
>
> ...
>
> my $l4p = AppX::Log4Perl->instance();
>
> $l4p->init_once('appx.conf');
>
> my $logger = $l4p->get_logger();
>
>
>
> .... then in another application sharing the same httpd:
>
> package AppY;
>
> use AppY::Log4Perl; # descends from Log::Log4Perl
>
> ...
>
> $l4p->init_once('appy.conf');
>
> my $logger = $l4p->get_logger();
>
>
>
>
>
> ... and AppX::Log4Perl will look like exactly like this:
>
>
>
> package AppX::Log4Perl;
>
> use strict;
>
> use base(Log::Log4Perl);
>
> 1;
>
> __END__
>
>
>
>
>
> I know it will be a major change to build this into Log::Log4Perl but I
> think it can be done while retaining backwards compatibility.
>
> All current class methods now can be automatically turned into both
> class and object methods at the same time like this:
>
> sub a_class_method {
>
>  my $proto = shift;
>
>  my $self = ref($proto)  ? $proto : $proto->instance();
>
>  }
>
> Actually the magic above can become more involved if necessary.
>
>
>
> Log::Log4Perl is a great piece of work.... I only miss that.
>
>
>
> In general when making packages, one must really scratch one's head a
> few times if deciding to use globals, because they are almost always
> unnecessary (except for constants) and a simple object or else
> Class::Singleton based alternative is almost always the solution.
>
>
>
> That's just my 2p.
>
>
>
> Regards,
>
> Craig Manley.
>
>