You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Weiming <sw...@gmail.com> on 2016/02/11 20:13:47 UTC

unit test 'errorhandlertestcase' failed

Hi,

I am a first-time user of log4cxx. I checked out the latest svn trunk and 
have successfully compiled the source code on Fedora 22. But 'make check' 
failed on the unit test 'errorhandlertestcase'.

My console output related to errorhandlertestcase is appended at the very 
end of this post for the reference.

Basically, it shows that "output/filtered" is empty, which should have the 
same content as "witness/fallback1".

I checked the source code at Line 79 of 
src/test/cpp/varia/errorhandlertestcase.cpp .

Transformer::transform("output/temp", "output/filtered", filters);

I didn't quite understand what Transformer::transform tries to achieve. Does 
it tries to filter out (delete) everything in "output/temp" which matches 
the patterns of the filters? If so, i think it makes sense for 
"output/filtered" to be empty.

Hope someone more familiar with the implementation can help me on 
troubleshooting this problem.

Thanks


===== Console output related to unit test 'errorhandlertestcase' =====

errorhandlertestcase: -log4cxx: DOMConfigurator configuring file 
input/xml/fallback1.xml...
log4cxx: debug attribute= "".
log4cxx: Ignoring internalDebug attribute.
log4cxx: Threshold ="".
log4cxx: Level value for root is [debug].
log4cxx: OptionConverter::toLevel: no class name specified, level=[debug]
log4cxx: root level set to DEBUG
log4cxx: Class name: [org.apache.log4j.FileAppender]
log4cxx: FB: Setting primary appender to [PRIMARY].
log4cxx: FB: Adding logger [root].
log4cxx: Class name: [org.apache.log4j.FileAppender]
log4cxx: Setting option name=[File], value=[output/temp]
log4cxx: Setting option name=[Append], value=[false]
log4cxx: Parsing layout of class: "org.apache.log4j.PatternLayout"
log4cxx: Setting option name=[ConversionPattern], value=[FALLBACK - %c - 
%m%n]
log4cxx: FB: Setting backup appender to [FALLBACK].
log4cxx: Setting option name=[File], value=[output/xyz/:x.log]
log4cxx: Setting option name=[Append], value=[false]
log4cxx: Parsing layout of class: "org.apache.log4j.PatternLayout"
log4cxx: Setting option name=[ConversionPattern], value=[%-5p %c{2} - %m%n]
log4cxx: Adding appender named [PRIMARY] to logger [root].
File [witness/fallback1] longer than file [output/filtered].
--------------------------------
Contents of output/filtered:
--------------------------------
Contents of witness/fallback1:
1   : FALLBACK - test - Message 0
2   : FALLBACK - root - Message 0
3   : FALLBACK - test - Message 1
4   : FALLBACK - root - Message 1
5   : FALLBACK - test - Message 2
6   : FALLBACK - root - Message 2
7   : FALLBACK - test - Message 3
8   : FALLBACK - root - Message 3
9   : FALLBACK - test - Message 4
10  : FALLBACK - root - Message 4
11  : FALLBACK - test - Message 5
12  : FALLBACK - root - Message 5
13  : FALLBACK - test - Message 6
14  : FALLBACK - root - Message 6
|Line 88: Compare::compare("output/filtered", "witness/fallback1") was 
expected to be true, was false.
FAILED 1 of 1




Re: unit test 'errorhandlertestcase' failed

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Thorsten Schöning,
am Freitag, 12. Februar 2016 um 08:56 schrieben Sie:

> So maybe the test is just wrong?

Don't think so anymore: I guess errorhandlertestcase failed on Linux
because :x.log is a valid file name there. That's not the case under
e.g. NTFS and from my understanding the purpose of the PRIMARY
appender is simply to fail to be used because of an invalid file name
and trigger FALLBACK that way. If that fails and logging into :x.log
succeeds, the test fails. So I changed the file name used to be ".",
which should be invalid in most cases.

This way the test succeeds in my Windows and Ubuntu as well.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


Re: unit test 'errorhandlertestcase' failed

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Weiming,
am Donnerstag, 11. Februar 2016 um 20:13 schrieben Sie:

> Basically, it shows that "output/filtered" is empty, which should have the
> same content as "witness/fallback1".

That's correct and it does so in my env.

> I didn't quite understand what Transformer::transform tries to achieve. Does
> it tries to filter out (delete) everything in "output/temp" which matches
> the patterns of the filters?

I don't think so, it applies the filters to each line and the filters
decide which lines are kept or removed. So one needs to look at the
filters applied in the test case and to me it seems that ControlFilter
gets a pattern which decides which lines are KEPT and I'm not sure
what LineNumberFilter is about currently. If I look at my "temp" file,
it doesn't contain any line numbers and input/xml/fallback1.xml
doesn't contain any as well. Additionally, it looks like ControlFilter
is a no-op currently? The pattern provided with operator<< doesn't
seem to be forwarded anywhere. If instead look at LineNumberFilter,
this does save pattern sin the instance.

So maybe the test is just wrong?

In the end, I think it would like to achieve that wrong lines in
output/temp are filtered until witness/fallback1 is the result. It's
currently the case in my env, but output/temp already contains the
needed lines 1:1. Don't know if that's right or wrong yet, but
ControlFilter applied without any filtering would of course don't
change anything and therefore the test would pass.

> If so, i think it makes sense for "output/filtered" to be empty.

That wouldn't make sense because "witness/fallback1" is not empty and
that's the expected result of the test.

If I understand Transformer::createSedCommandFile correctly, "sed" is
used to perform the actual pattern matching at least for
LineNumberFilter. Is that available in your PATH? It should because
else log4cxx would assert, but you may want to make sure. Additionally
you should make sure that your "sed" accepts the used -f arg and the
patterns of "temp.sed". You can see the content of that file if you
run the test suite with only the one test you are interested it,
something like:

> test_all.cmd errorhandlertestcase

where test_all.cmd is some wrapper of mine to adopt the suite to my
needs. My temp.sed contains the following:

> sQ [^ ]*[\\]Q Qg
> sQ([0-9]*)Q(X)Qg

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow