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

2007-11-30 Thread Mike Schilli
On Thu, 22 Nov 2007, Merijn Broeren wrote:

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

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

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

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

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

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

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

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

use Log::Log4perl qw(:module_check_via_eval);

Other ideas?

-- Mike

Mike Schilli
[EMAIL PROTECTED]

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

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
log4perl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/log4perl-devel


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

2007-11-30 Thread Mike Schilli
On Fri, 23 Nov 2007, Johannes Kilian wrote:

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

Hmm, the following works for me:

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

eval {
LOGDIE "Waah!";
};

print "Survived!\n";

and prints

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

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

-- Mike

Mike Schilli
[EMAIL PROTECTED]

> 4.) Finishing my program an error from log4perl occurs: (in cleanup) 
> Internal error: Root Logger not initialized. at 
> C:/Programme/Perl/site/lib/Log/Log4perl/Logger.pm line 557 during global 
> destruction.
>
> What's going on? What can I do to make $logger->logdie(...)  to be catchable 
> with eval{} again?
>
> Any help welcome ...
>
> Johannes
>
> As an appendix, my Log4perl-configuration (quite complex):
>
> 
> 
> http://log4perl.sourceforge.net/";
> threshold="debug"
> oneMessagePerAppender="true">
> 
> 
> 
> class="Log::Log4perl::Appender::File">
> value="sub { 
> Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' => 'FULL'); };" 
> />
> value="write" />
> value="1" />
>   
>   class="org.apache.log4j.PatternLayout">
> value="%d %p [%c]: %m%n" />
>   
> 
> class="Log::Log4perl::Appender::File">
> value="sub { 
> Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' => 'ERR'); };" 
> />
> value="write" />
> value="1" />
>   
>   class="org.apache.log4j.PatternLayout">
> value="%d %p [%c]: %m%n" />
>   
> 
> class="Log::Log4perl::Appender::Screen">
>   
>   class="org.apache.log4j.PatternLayout">
> value="%d %p [%c]: %m%n" />
>   
> 
> class="Log::Log4perl::Appender::File">
> value="sub { 
> Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' => 'DEBUG'); 
> };" />
> value="write" />
> value="1" />
>   
>   class="org.apache.log4j.PatternLayout">
> value="%d{HH:mm:ss} [%c] %p: %m%n" />
>   
> 
> class="Log::Log4perl::Appender::File">
> value="sub { 
> Vitronic::BuildSteps::MiscBuildStep::getLogfileName('TYPE' => 'SQL'); };" 
> />
> value="write" />
> value="1" />
>   
>   class="org.apache.log4j.PatternLayout">
> value="%d %p [%c]: %m%n" />
>   
> 
> 
> class="Log::Log4perl::Appender::Synchronized">
> value="AppDebugFile" />
> 
> 
> 
> 
>   class="Log::Log4perl::Filter::LevelRange">
> value="DEBUG" />
> value="FATAL" />
> value="true" />
> 
>   class="Log::Log4perl::Filter::LevelRange">
> value="INFO" />
> value="FATAL" />
> value="true" />
> 
>   class="Log::Log4perl::Filter::LevelRange">
> value="ERROR" />
> value="FATAL" />
> value="true" />
> 
> 
> 
> 
> 
>   
>   
>   
>   
> 
> 
>additivity="false">
>   
>   
> 
>additivity="false">
>   
>   
> 
> 
>   
>   
> 
>additivity="false">
>   
>   
> 
>
>
>
>
> --
> GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
> Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
>

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
log4perl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/log4perl-devel