Re: ERROR org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse
Hi Thorsten,
I wanted to ask for that stacktrace anyway: )
Seems WebPageRenderer thinks it has to store the rendering result and
redirect to it.
That's definitely nothing something you want to have when using
ComponentRenderer.
There's probably something in your setup that triggers this redirect
(e.g. page url changes after render). Maybe we could improve
ComponentRender so it never redirects.
Best regards
Sven
On 01.04.20 19:53, Thorsten Schöning wrote:
Guten Tag Sven Meier,
am Mittwoch, 1. April 2020 um 17:31 schrieben Sie:
Without a quickstart it's hard to guess whether this is an error
actually or you did something wrong.
Things are easy in my opinion: There's no session-ID in my use case at
all, the code itself is tolerant and many other places are as well,
like BufferedResponseMapper:
protected String getSessionId()
{
String sessionId = null;
if (Application.exists() && RequestCycle.get() != null)
{
[...]
Session session =
sessionStore.lookup(requestCycle.getRequest());
if (session != null)
{
sessionId = session.getId();
}
}
return sessionId;
}
protected boolean hasBufferedResponse(Url url)
{
String sessionId = getSessionId();
boolean hasResponse = false;
if (Strings.isEmpty(sessionId) == false)
{
hasResponse =
WebApplication.get().hasBufferedResponse(sessionId, url);
}
return hasResponse;
}
I tried to reproduce this using a quickstart but failed, it's too much
work to get all my components/customizations into place to see which
triggers the code path. The original quickstart doesn't seem to
trigger it.
So my approach is different, I'm simply overriding the method in
question and make it more tolerant myself. This allows me to get a
stacktrace of the code path triggered as well:
java.lang.UnsupportedOperationException: foobar
at
de.am_soft.sm_mtg.view.report.VwrRenderApp.storeBufferedResponse(VwrRenderApp.java:112)
at
org.apache.wicket.request.handler.render.WebPageRenderer.storeBufferedResponse(WebPageRenderer.java:87)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:278)
at
org.apache.wicket.util.tester.BaseWicketTester$LastPageRecordingPageRendererProvider$1.respond(BaseWicketTester.java:2824)
at
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:202)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:914)
at
org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:65)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:282)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:253)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)
at
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:713)
at
org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:652)
at
org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:879)
at
org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:896)
at
de.am_soft.sm_mtg.view.report.html.pages.meter_cnt.some_month.VwrPgMcsmSummaryTest.wicket(VwrPgMcsmSummaryTest.java:63)
try (VwrCtxThreadScoped scopedCtx = new
VwrCtxThreadScoped(ctx0))
{
Supplier page= () -> new
VwrPgMcsmSummary();
VwrRenderAppapp = new
VwrRenderApp(page);
WicketTestertester = new
WicketTester(app);
tester.startPage(page.get());
}
Mit freundlichen Grüßen,
Thorsten Schöning
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: update DropDownList via AJAX
Hi, if the DropDownList is updated via Ajax, the DOM element gets replaced and the closes, I don't see a way around that. You could try updating the select's inner (via some Ajax JS magic) only. I'm not aware of a pre-build Wicket solution that would do that though. Maybe Select2 or similar can help you with that. Have fun Sven On 01.04.20 11:35, Sretan wrote: Hello, I have one TextField and one DropDownList. When i enter example '1' in the TextField and after that click on the DropDownList, DropDownList is opened and at the same time is updated from the server (because of the event fired from TextField) via AJAX. The DropDownList list is updated and closed. I must click again on DropDownList to open it. Can some how this closing be prevented or any other ideas how to solve this? I am using wicket 6.13. Thanks -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ERROR org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse
Guten Tag Sven Meier,
am Mittwoch, 1. April 2020 um 17:31 schrieben Sie:
> Without a quickstart it's hard to guess whether this is an error
> actually or you did something wrong.
Things are easy in my opinion: There's no session-ID in my use case at
all, the code itself is tolerant and many other places are as well,
like BufferedResponseMapper:
> protected String getSessionId()
> {
> String sessionId = null;
>
> if (Application.exists() && RequestCycle.get() != null)
> {
> [...]
> Session session =
> sessionStore.lookup(requestCycle.getRequest());
> if (session != null)
> {
> sessionId = session.getId();
> }
> }
>
> return sessionId;
> }
> protected boolean hasBufferedResponse(Url url)
> {
> String sessionId = getSessionId();
> boolean hasResponse = false;
> if (Strings.isEmpty(sessionId) == false)
> {
> hasResponse =
> WebApplication.get().hasBufferedResponse(sessionId, url);
> }
> return hasResponse;
> }
I tried to reproduce this using a quickstart but failed, it's too much
work to get all my components/customizations into place to see which
triggers the code path. The original quickstart doesn't seem to
trigger it.
So my approach is different, I'm simply overriding the method in
question and make it more tolerant myself. This allows me to get a
stacktrace of the code path triggered as well:
> java.lang.UnsupportedOperationException: foobar
> at
> de.am_soft.sm_mtg.view.report.VwrRenderApp.storeBufferedResponse(VwrRenderApp.java:112)
> at
> org.apache.wicket.request.handler.render.WebPageRenderer.storeBufferedResponse(WebPageRenderer.java:87)
> at
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:278)
> at
> org.apache.wicket.util.tester.BaseWicketTester$LastPageRecordingPageRendererProvider$1.respond(BaseWicketTester.java:2824)
> at
> org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:202)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:914)
> at
> org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:65)
> at
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:282)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:253)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)
> at
> org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:713)
> at
> org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:652)
> at
> org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:879)
> at
> org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:896)
> at
> de.am_soft.sm_mtg.view.report.html.pages.meter_cnt.some_month.VwrPgMcsmSummaryTest.wicket(VwrPgMcsmSummaryTest.java:63)
> try (VwrCtxThreadScoped scopedCtx = new
> VwrCtxThreadScoped(ctx0))
> {
> Supplier page= () -> new
> VwrPgMcsmSummary();
> VwrRenderAppapp = new
> VwrRenderApp(page);
> WicketTestertester = new
> WicketTester(app);
>
> tester.startPage(page.get());
> }
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: ERROR org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse
Hi Thorsten,
the log message seems to have served it's purpose:
You reported the problem :P.
Without a quickstart it's hard to guess whether this is an error
actually or you did something wrong.
Sven
On 01.04.20 17:06, Thorsten Schöning wrote:
Hi all
I have a project in which I use Wicket as some rendering engine only,
without actual HTTP-requests of any kind. As has been advised here in
the past, this is done using ComponentRenderer and some custom mocks
for the serializer and session store. The latter are pretty much what
is used within ComponentRenderer as well already.
Additionally I started using WicketTester in that project to test
things and during running tests I get the following errors logged:
16:31:21 ERROR
org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse:
storeBufferedResponse needs a valid session id to store the
response, but a null one was found. Please report the problem to dev
team and try to reproduce it in a quickstart project.
Nevertheless, things succeed, because the logging code simply returns
and in that case it doesn't seem to make any difference:
public void storeBufferedResponse(String sessionId, Url url,
BufferedWebResponse response)
{
if (Strings.isEmpty(sessionId))
{
log.error("storeBufferedResponse needs a valid session id
to store the response, but a null one was found. "
+ "Please report the problem to dev team
and try to reproduce it in a quickstart project.");
return;
}
String key = sessionId + url.toString();
storedResponses.put(key, response);
}
Shouldn't this be changed to at least a warning, if not removed
entirely?
Both of my cases seem to be valid use cases in the end. So logging an
error when things can't ever work this way in those use cases seems
overkill and unnecessary alarming to me.
Mit freundlichen Grüßen,
Thorsten Schöning
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
ERROR org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse
Hi all
I have a project in which I use Wicket as some rendering engine only,
without actual HTTP-requests of any kind. As has been advised here in
the past, this is done using ComponentRenderer and some custom mocks
for the serializer and session store. The latter are pretty much what
is used within ComponentRenderer as well already.
Additionally I started using WicketTester in that project to test
things and during running tests I get the following errors logged:
> 16:31:21 ERROR
> org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse:
> storeBufferedResponse needs a valid session id to store the
> response, but a null one was found. Please report the problem to dev
> team and try to reproduce it in a quickstart project.
Nevertheless, things succeed, because the logging code simply returns
and in that case it doesn't seem to make any difference:
> public void storeBufferedResponse(String sessionId, Url url,
> BufferedWebResponse response)
> {
> if (Strings.isEmpty(sessionId))
> {
> log.error("storeBufferedResponse needs a valid
> session id to store the response, but a null one was found. "
> + "Please report the problem to dev
> team and try to reproduce it in a quickstart project.");
> return;
> }
>
> String key = sessionId + url.toString();
> storedResponses.put(key, response);
> }
Shouldn't this be changed to at least a warning, if not removed
entirely?
Both of my cases seem to be valid use cases in the end. So logging an
error when things can't ever work this way in those use cases seems
overkill and unnecessary alarming to me.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Where does Wickets debug-output when running tests in Gradle come from?
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.schoen...@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
logback-test.xml
Description: XML document
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Where does Wickets debug-output when running tests in Gradle come from?
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.schoen...@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
logback-test.xml
Description: XML document
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
update DropDownList via AJAX
Hello, I have one TextField and one DropDownList. When i enter example '1' in the TextField and after that click on the DropDownList, DropDownList is opened and at the same time is updated from the server (because of the event fired from TextField) via AJAX. The DropDownList list is updated and closed. I must click again on DropDownList to open it. Can some how this closing be prevented or any other ideas how to solve this? I am using wicket 6.13. Thanks -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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.schoen...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
