You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2020/04/01 09:46:32 UTC
Where does Wickets debug-output when running tests in Gradle come from?
Hi all,
I'm using Gradle and recently started to run tests using Wicket
rendering some contents. Things work pretty well, but Wicket provides
a lot of DEBUG-output on STDOUT or STDERR, which Gradle puts into its
own HTML-reports for results of tests.
This makes those reports pretty large in my case, e.g. ~24 MiB, and
therefore takes a pretty long time to view in the browser. As well,
when running those tests using the integration into Eclipse, that
blocks for around half a minute as well, because each individual line
of Wicket DEBUG-output is added to some GUI-tree view.
Output looks e.g. like the following, only 10 thousands of lines more:
> 11:34:01.536 [Test worker] INFO org.apache.wicket.Application - [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: org.wicketstuff.event.annotation.Initializer@3456cd50
> 11:34:01.546 [Test worker] INFO org.apache.wicket.Application - [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: Wicket core library initializer
> 11:34:01.569 [Test worker] DEBUG o.a.w.p.h.servlet.ServletWebRequest - Calculating context relative path from: context path '/context', filterPrefix 'servlet/', uri '/context/servlet/'
Any idea why that output is triggered?
I thought it might be bound to Gradle's own log levels somehow, but
switching between "--quiet" and "--debug" really only changes how much
Gradle logs on STDOUT, not what Wicket does. Additionally, I don't see
any other debugging output, besides some of my own classes using SLF4J
as well.
This leaves some logging-backend with some explicit configuration
only, doesn't it? Something like log4j2, Logback or else with some
config, but couldn't find some yet.
Is there something embedded in Wicket used automatically when the
teser is used?
Thanks for your ideas!
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Where does Wickets debug-output when running tests in Gradle come from?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Thorsten Schöning,
am Mittwoch, 1. April 2020 um 11:46 schrieben Sie:
>> 11:34:01.536 [Test worker] INFO org.apache.wicket.Application - [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: org.wicketstuff.event.annotation.Initializer@3456cd50
>> 11:34:01.546 [Test worker] INFO org.apache.wicket.Application - [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: Wicket core library initializer
>> 11:34:01.569 [Test worker] DEBUG o.a.w.p.h.servlet.ServletWebRequest - Calculating context relative path from: context path '/context', filterPrefix 'servlet/', uri '/context/servlet/'
> Any idea why that output is triggered?
Things were easier than expected: Logback was simply available on the
classpath for some reason, loaded, didn't find a configuration and
therefore configured itself to its defaults: Using the console.
Making a logback-test.xml available in "src/test/resources" with
higher log levels easily resolved those debugging messages and the
generated reports of Gradle or small again.
I tried a different approach before: Expactation was that in case
tests fail, at least the last X log statements might be of use to
debug the problem, but really only then. While Gradle doesn't provide
anything like that on its own, there are examples to do so on SO and
other places:
https://stackoverflow.com/a/51786839/2055163
The basic approach is using some listener to log into some cache in
the background and only print those contents when the tests have
failed. Logging in the background needs to be implemented, but
additonally its important to tell Gradle that really only some
statements should be logged at all:
> tasks.withType(Test) {
> testLogging {
> events 'failed' // TestLogEvent.FAILED
> }
> }
While that should work in theory, I ran into two problems: Whatever I
did I wasn't able to reduce what Gradle logs on STDOUT. It's important
to note that the implemented logging cache int he background DOES NOT
prevent logging, it's only for additional maintenance. The events-part
is what prevents logging of some sort in theory. That is even for
multiple different log level, but things didn't change even for
setting all of those to "failed" for some reason.
Even if things have succeeded, I might only not have recognized,
becuase at some point I disabled Gradle's logging again, so wouldn't
see a difference anway. Nevetheless, the generated test-reports were
always still huge and always contained the whole output of STDOUT.
So things simply didn't work in the end and falling back to
logback-test.xml was the best I coud do. In case anyone is interested,
I added my PoC.
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: Where does Wickets debug-output when running tests in Gradle come from?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Thorsten Schöning,
am Mittwoch, 1. April 2020 um 11:46 schrieben Sie:
>> 11:34:01.536 [Test worker] INFO org.apache.wicket.Application - [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: org.wicketstuff.event.annotation.Initializer@3456cd50
>> 11:34:01.546 [Test worker] INFO org.apache.wicket.Application - [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: Wicket core library initializer
>> 11:34:01.569 [Test worker] DEBUG o.a.w.p.h.servlet.ServletWebRequest - Calculating context relative path from: context path '/context', filterPrefix 'servlet/', uri '/context/servlet/'
> Any idea why that output is triggered?
Things were easier than expected: Logback was simply available on the
classpath for some reason, loaded, didn't find a configuration and
therefore configured itself to its defaults: Using the console.
Making a logback-test.xml available in "src/test/resources" with
higher log levels easily resolved those debugging messages and the
generated reports of Gradle or small again. Though already available,
it might make sense to require logback to be available during running
tests always:
> testRuntimeOnly 'ch.qos.logback:logback-classic:1.1.3',
> 'ch.qos.logback:logback-core:1.1.3',
> 'org.junit.jupiter:junit-jupiter-engine:5.1.0'
I tried a different approach before: Expactation was that in case
tests fail, at least the last X log statements might be of use to
debug the problem, but really only then. While Gradle doesn't provide
anything like that on its own, there are examples to do so on SO and
other places:
https://stackoverflow.com/a/51786839/2055163
The basic approach is using some listener to log into some cache in
the background and only print those contents when the tests have
failed. Logging in the background needs to be implemented, but
additonally its important to tell Gradle that really only some
statements should be logged at all:
> tasks.withType(Test) {
> testLogging {
> events 'failed' // TestLogEvent.FAILED
> }
> }
While that should work in theory, I ran into two problems: Whatever I
did I wasn't able to reduce what Gradle logs on STDOUT. It's important
to note that the implemented logging cache int he background DOES NOT
prevent logging, it's only for additional maintenance. The events-part
is what prevents logging of some sort in theory. That is even for
multiple different log level, but things didn't change even for
setting all of those to "failed" for some reason.
Even if things have succeeded, I might only not have recognized,
becuase at some point I disabled Gradle's logging again, so wouldn't
see a difference anway. Nevetheless, the generated test-reports were
always still huge and always contained the whole output of STDOUT.
Might be that Gradle simply works that way and doesn't support
anything else at all:
https://discuss.gradle.org/t/disabling-stdout-stderr-generated-by-unit-tests-and-captured-in-the-test-results-xml-files/6546
So things simply didn't work in the end and falling back to
logback-test.xml was the best I coud do. In case anyone is interested,
I added my PoC.
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