[log4perl-devel] Can caller_depth be set per logger
Hi, I mailed this question some months ago and did not get any response so I thought I'd have one last go slightly reworded. I have many different loggers in the same application in the program itself and various modules. One module is a wrapper class around DBI and has to set the caller_depth to 2 but caller_depth seems to be global and hence this affects all other loggers in the same program. Is there any way to set caller_depth per logger? My precise example was in my post on this list 3-dec-07. Thanks Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ log4perl-devel mailing list log4perl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] Change in behavior when upgrading to 1.26 and perl 5.10.0
>>
>># Note that (4) L4pSubclass->get_logger() => ("L4pSubclass")
>># is indistinguishable from (3) and therefore can't be allowed.
>># Wrapper classes always have to specify the category explicitely.
>>
>>my $category;
>>
>>if(@_ == 0) {
>> # 1
>>$category = scalar caller($Log::Log4perl::caller_depth);
>>} elsif(@_ == 1) {
>> # 2, 3
>>if($_[0] eq __PACKAGE__) {
>> # 2
>>$category = scalar caller($Log::Log4perl::caller_depth);
>>} else {
>>$category = $_[0];
>>}
>>} else {
>> # 5, 6
>>$category = $_[1];
>>}
>>
>># Delegate this to the logger module
>>return Log::Log4perl::Logger->get_logger($category);
>> }
>>
>>
>> Here is an example:
>>
>> 1.pl
>>
>>
>> use Log::Log4perl qw(get_logger :levels);
>> use DBIx::Log4perl;
>>
>> Log::Log4perl->init_and_watch('x.conf', 60);
>>
>> my $a = DBIx::Log4perl->new();
>>
>> Log4perl.pm (put this in a dir called DBIx)
>> ===
>>
>> package DBIx::Log4perl;
>>
>> sub new
>> {
>>
>>local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth
>> + 1;
>>$h = Log::Log4perl->get_logger();
>>
>>$h->debug("log msg");
>>
>> }
>> 1;
>>
>> x.conf
>> ==
>>
>> log4perl.logger=ERROR
>> log4perl.logger.Server = INFO
>> log4perl.logger.DBIx.Log4perl=DEBUG, X1
>> log4perl.appender.X1=Log::Log4perl::Appender::File
>> log4perl.appender.X1.filename=dbix.log
>> log4perl.appender.X1.mode=append
>> log4perl.appender.X1.utf8 = 1
>> log4perl.appender.X1.umask = sub { 0002 }
>> log4perl.appender.X1.layout=Log::Log4perl::Layout::PatternLayout
>> log4perl.appender.X1.layout.ConversionPattern=%d %p> %F{1}:%L %M - %m%n
>>
>> then run
>> perl -I/dir_where_DBIx_dir_is 1.pl
>>
>> nothing comes out in log. Change the depth after get_logger and it
>> works.
>>
>> Martin
>> --
>> Martin J. Evans
>> Easysoft Limited
>> http://www.easysoft.com
>>
>> --
>>
>>
>> Return on Information:
>> Google Enterprise Search pays you back
>> Get the facts.
>> http://p.sf.net/sfu/google-dev2dev
>> ___
>> log4perl-devel mailing list
>> log4perl-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/log4perl-devel
>>
>
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] Change in behavior when upgrading to 1.26 and perl 5.10.0
Mike Schilli wrote:
> Thanks for the detailed description, here's what's happening:
>
> This change in behavior was caused by a patch introduced with
> Log-Log4perl-1.19 in
>
>
> http://github.com/mschilli/log4perl/commit/35d86ae53859424ea3ac357eaf0f15d9e69f4bed
>
>
> in September 2008. A detailed description of the issue at the time is
> available in
>
> http://rt.cpan.org/Ticket/Display.html?id=38356
>
> on the request tracker. It fixed problems with the caller_depth, but it
> also introduced a change to get_logger() which bumped up the caller()
> level to obtain the category (aka package name) of the calling package.
>
> This is probably a good opportunity to rethink how Log4perl wrapper
> classes should be implemented.
>
> To implement a L4p wrapper class correctly, it needs to provide the
> following four methods:
>
> 1 Wrap::get_logger()
> 2 Wrap::get_logger( $package )
> 3 Wrap->get_logger()
> 4 Wrap->get_logger( $package )
>
> Calls #1 and #3 are supposed to obtain a logger with the category of the
> calling package, not the category of the wrapper package. This is
> especially difficult in case #3, as Log4perl doesn't know if "Wrap" is
> a Log4perl wrapper or if it's the #2 signature where "$package" is an
> application package called "Wrap".
>
> Another complication is that we don't know how "Wrap" is implemented.
> Is it relaying the get_logger() call to Log4perl by implementing its own
> get_logger function? Or is it simply inheriting from Log4perl?
>
> I've put together a fix to resolve this, please check out the
> documentation:
>
>
> http://github.com/mschilli/log4perl/commit/8ad3fbae60a4667aba848eb545c66339aeff161a
>
>
> As this might break backward compatibility with earlier versions of
> Log4perl, I'm interested in hearing what you think about it, feedback
> definitely welcome. If I don't hear anything back, it'll go out with the
> next release.
>
> You can play around with the new implementation, here's the tarball:
>
> http://github.com/mschilli/log4perl/tarball/wrapper_fix
>
> Also, I've opened a bug on RT to track this issue:
>
> https://rt.cpan.org/Ticket/Display.html?id=52913
>
> Give it a spin!
>
> -- Mike
>
> Mike Schilli m...@perlmeister.com
Thank you Mike. I've tried this now and it appears to fix the change in
behaviour I reported and does not appear to break anything else I can
see. I am now using the tarball you provided and will report if I see
anything. I will also update the rt later today.
Thanks again
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
> On Wed, 9 Dec 2009, Martin Evans wrote:
>
>> Mike Schilli wrote:
>>> On Wed, 9 Dec 2009, Martin Evans wrote:
>>>
>>>> Since the upgrade we are getting no logging in one of the files we
>>>> expected to get it. After a bit of searching around I discovered the
>>>> module we were using was doing this:
>>>>
>>>> local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1;
>>>> $h{logger} = Log::Log4perl->get_logger();
>>>> and the fix was to change the order of those lines.
>>>
>>> Thanks for reporting this, although I have a hard time imaginining how
>>> increasing the caller_depth and then getting a logger would be different
>>> from what you'd get if you did it in the reverse order. Not to mention
>>> that it's puzzling why this would change the logging behavior, as
>>> caller_depth is used mainly for cosmetic reasons in certain features
>>> of the pattern layout.
>>>
>>> Can you provide a snippet of code that reproduces the problem in full?
>>> That would really help track down the root of the problem.
>>>
>>> Thanks!
>>>
>>> -- Mike
>>>
>>> Mike Schilli
>>> m...@perlmeister.com
>>>
>>>
>>
>> It was ending up with "main" and the category in the following code
>> instead of DBIx::Log4perl.
>>
>>
>> sub get_logger { # Get an instance (shortcut)
>> ##
>># get_logger() can be called in the following ways:
>>#
>># (1) Log::Log4perl::get_logger() => ()
>># (2) Log::Log4perl->get_logger() => ("Log::Log4perl")
>># (3) Log::Log4perl::get_logger($cat) => ($cat)
>>#
>># (5) Log::Log4perl->get_logger($cat) => ("Log::Log
[log4perl-devel] Why is Log::Log4perl opening unreferenced log files and can I stop it
Hi, I have a number of daemon processes using Log::Log4perl and tens of modules shared between them also using Log::Log4perl. All the log4perl configuration is in a single file for convenience (as most modules in it are common). Each perl module has its own log entry and logs to a different file. The problem is there are ALOT of different log files defined and Log4perl seems to open every file mentioned in the config file even though only a handful might be used. e.g., config: log4perl.logger.XXX.module1 = INFO, MONE log4perl.appender.MONE=Log::Dispatch::File log4perl.appender.MONE.filename=/tmp/file1.log log4perl.logger.XXX.module2 = INFO, MTWO log4perl.appender.MTWO=Log::Dispatch::File log4perl.appender.MTWO.filename=/tmp/file2.log . . . etc and daemon1 uses module XXX::module1 but not XXX.module2, the /tmp/file2.log is opened in daemon1 even though it is never going to be logged to. This is rather annoying since it is using up my open file descriptors etc. Using lsof on a single daemon shows dozens of log files open even though there is NO chance it will log anything to them. Is there any way to stop this? Thanks. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ log4perl-devel mailing list log4perl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] Why is Log::Log4perl opening unreferenced log files and can I stop it
Kevin Goess wrote: > Martin, see 'perldoc Log4perl::Appender::File > > create_at_logtime > The file appender typically creates its logfile in its constructor, i.e. > at Log4perl "init()" time. This > is desirable for most use cases, because it makes sure that file > permission problems get detected right > away, and not after days/weeks/months of operation when the appender > suddenly needs to log something and > fails because of a problem that was obvious at startup. > > However, there are rare use cases where the file shouldn’t be created at > Log4perl "init()" time, e.g. if > the appender can’t be used by the current user although it is defined in > the configuration file. If you > set "create_at_logtime" to a true value, the file appender will try to > create the file at log time. Note > that this setting lets permission problems sit undetected until log > time, which might be undesirable. Kevin, Thanks for pointing that out although I guess I missed this because I was using Log::Dispatch::File (which does not have create_at_log) and not Log::Log4perl::Appender::File. When I change to Log::Log4perl::Appender::File and set the create_at_log it works fine. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com > > > Martin J. Evans wrote: >> Hi, >> >> I have a number of daemon processes using Log::Log4perl and tens of >> modules shared between them also using Log::Log4perl. All the log4perl >> configuration is in a single file for convenience (as most modules in it >> are common). Each perl module has its own log entry and logs to a >> different file. The problem is there are ALOT of different log files >> defined and Log4perl seems to open every file mentioned in the config >> file even though only a handful might be used. e.g., >> >> config: >> log4perl.logger.XXX.module1 = INFO, MONE >> log4perl.appender.MONE=Log::Dispatch::File >> log4perl.appender.MONE.filename=/tmp/file1.log >> >> log4perl.logger.XXX.module2 = INFO, MTWO >> log4perl.appender.MTWO=Log::Dispatch::File >> log4perl.appender.MTWO.filename=/tmp/file2.log >> . >> . >> . >> etc >> >> and daemon1 uses module XXX::module1 but not XXX.module2, the >> /tmp/file2.log is opened in daemon1 even though it is never going to be >> logged to. This is rather annoying since it is using up my open file >> descriptors etc. >> >> Using lsof on a single daemon shows dozens of log files open even though >> there is NO chance it will log anything to them. >> >> Is there any way to stop this? >> >> Thanks. >> >> Martin >> > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ log4perl-devel mailing list log4perl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/log4perl-devel
[log4perl-devel] logwarn not calling warn if L::L's init not called
Hi,
Is this really the intended behaviour:
perl -w -le 'use strict;use warnings;use Log::Log4perl qw(get_logger); my $lh =
get_logger("BET::Data::Remove"); $lh->debug("fred");$lh->logwarn("warning from
l:l"); warn("warning");'
Log4perl: Seems like no initialization happened. Forgot to call init()?
warning at -e line 1.
i.e., if something does not call init for Log::Log4perl but has a log handle
when logwarn is called a warn does not happen?
So substituting warn with logwarn does not always warn!
I spent some time debugging a problem this morning only to discover this. I
find this most worrying as I'd expect the warn to happen whatever. If you
substitute logdie for die it seems to work.
perl -MLog::Log4perl -le 'print $Log::Log4perl::VERSION;'
1.33
This is perl, v5.10.1 (*) built for i686-linux-gnu-thread-multi
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] logwarn not calling warn if L::L's init not called
On 21/11/11 04:46, Mike Schilli wrote:
> On Tue, 1 Nov 2011, Martin J. Evans wrote:
>
>> So substituting warn with logwarn does not always warn!
>
> That's an interesting case. The way it's implemented right now is that
> logwarn() will only call warn() (along with other log4perl actions) if
> the log level is greater or equal than WARN.
>
> logdie(), on the other hand, will call die() unconditionally, because
> it's an action, not only a message.
>
> -- -- Mike
So simply substituting warn with logwarn can change the way your program works.
It is not for me to tell you how Log::Log4perl should work but I find this
behaviour unacceptable as my program will behave differently depending on the
log level. Logging should be logging, not changing the way my program runs.
Example:
$ perl -le '$SIG{__WARN__} = sub {CORE::die "Warning:\n", @_, "\n"}; use
Log::Log4perl qw(get_logger); my $lh =
get_logger("BET::Data::Remove");warn("fred"); print "ok";'
Warning:
fred at -e line 1.
Change the warn to logwarn:
$ perl -le '$SIG{__WARN__} = sub {CORE::die "Warning:\n", @_, "\n"}; use
Log::Log4perl qw(get_logger); my $lh =
get_logger("BET::Data::Remove");$lh->logwarn("fred"); print "ok";
ok
Would you consider changing this? If not, I would be most grateful if you could
you point me at the place where I could change this behaviour or tell my how I
could override it.
Martin
>> Hi,
>>
>> Is this really the intended behaviour:
>>
>> perl -w -le 'use strict;use warnings;use Log::Log4perl qw(get_logger); my
>> $lh = get_logger("BET::Data::Remove");
>> $lh->debug("fred");$lh->logwarn("warning from l:l"); warn("warning");'
>>
>> Log4perl: Seems like no initialization happened. Forgot to call init()?
>> warning at -e line 1.
>>
>> i.e., if something does not call init for Log::Log4perl but has a log handle
>> when logwarn is called a warn does not happen?
>>
>
>>
>> I spent some time debugging a problem this morning only to discover this. I
>> find this most worrying as I'd expect the warn to happen whatever. If you
>> substitute logdie for die it seems to work.
>>
>> perl -MLog::Log4perl -le 'print $Log::Log4perl::VERSION;'
>> 1.33
>> This is perl, v5.10.1 (*) built for i686-linux-gnu-thread-multi
>>
>> Martin
>>
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] logwarn not calling warn if L::L's init not called
On 24/12/11 01:01, Mike Schilli wrote:
> On Mon, 21 Nov 2011, Martin J. Evans wrote:
>
>> Would you consider changing this? If not, I would be most grateful if
>> you could you point me at the place where I could change this
>> behaviour or tell my how I could override it.
>
> Alright, I gave in and fixed it :)
Excellent and thank you.
> https://github.com/mschilli/log4perl/commit/7d7fbbb45254d6c903f5b3cb91d7
>
> Thanks for bringing this to my attention. Please give it a whirl!
I have /whirled/ it and it a) now warns when it didn't before and b) seems to
still work in all other ways we are using it.
Thanks again.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
>
>>
>> Martin
>>
>>>> Hi,
>>>>
>>>> Is this really the intended behaviour:
>>>>
>>>> perl -w -le 'use strict;use warnings;use Log::Log4perl qw(get_logger); my
>>>> $lh = get_logger("BET::Data::Remove");
>>>> $lh->debug("fred");$lh->logwarn("warning from l:l"); warn("warning");'
>>>>
>>>> Log4perl: Seems like no initialization happened. Forgot to call init()?
>>>> warning at -e line 1.
>>>>
>>>> i.e., if something does not call init for Log::Log4perl but has a log
>>>> handle when logwarn is called a warn does not happen?
>>>>
>>>
>>>>
>>>> I spent some time debugging a problem this morning only to discover this.
>>>> I find this most worrying as I'd expect the warn to happen whatever. If
>>>> you substitute logdie for die it seems to work.
>>>>
>>>> perl -MLog::Log4perl -le 'print $Log::Log4perl::VERSION;'
>>>> 1.33
>>>> This is perl, v5.10.1 (*) built for i686-linux-gnu-thread-multi
>>>>
>>>> Martin
>>>>
>>
>>
>>
>
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
[log4perl-devel] panic in sv_setpvn
panic: sv_setpvn called with negative strlen at
/home/perlbrew//perls/perl-5.14.2/lib/site_perl/5.14.2/Log/Log4perl/Layout/PatternLayout.pm
line 358.
That line in my distribution is:
##
sub shrink_category {
##
my($category, $len) = @_;
my @components = split /\.|::/, $category; # <-- here
if(@components > $len) {
splice @components, 0, @components - $len;
$category = join '.', @components;
}
return $category;
}
perl -MLog::Log4perl -le 'print $Log::Log4perl::VERSION;'
1.36
This is Perl 5.14.2 on Linux 32 bit machine built as default via perlbrew.
Any ideas.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
