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 15:06:15 UTC
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.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: ERROR org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Sven Meier,
am Mittwoch, 1. April 2020 um 21:09 schrieben Sie:
> 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.
Agreed, but I couldn't find yet why it thinks so. Additionally, as I
get the correct render result, the redirect target seems to be the
expected outpout anyway? So is trying to buffering the "problem" here
or the redirect already or both?
> There's probably something in your setup that triggers this redirect
> (e.g. page url changes after render).
I can't think of dealing with URLs beyond "setAutomaticLinking", but
will have a look at this later: Im rendering HTML and some plain-text
format using Wicket, in the latter case transforming HTML-links using
TransformerBehavior to something like the following:
> Linktext: HREF
And the error really gets only logged when rendering HTML, NOT when
rendering plain text. The app used to render both formats and their
base page is the same, though. Difference is markup and things like
TransformerBehaviour.
> Maybe we could improve ComponentRender so it never redirects.
And throw an exception to find that unexpected redirect or simply
ignore it at all? If that redirect-by-accident leads to wrong results,
an exception w9ould be good. Otherwise in my case I might not care too
much, as results are simply as expected.
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: ERROR
org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse
Posted by Sven Meier <sv...@meiers.net>.
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<VwrHtmlPage> page = () -> new VwrPgMcsmSummary();
>> VwrRenderApp app = new VwrRenderApp(page);
>> WicketTester tester = new WicketTester(app);
>>
>> tester.startPage(page.get());
>> }
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: ERROR org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse
Posted by Thorsten Schöning <ts...@am-soft.de>.
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<VwrHtmlPage> page = () -> new VwrPgMcsmSummary();
> VwrRenderApp app = new VwrRenderApp(page);
> WicketTester tester = new WicketTester(app);
>
> tester.startPage(page.get());
> }
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: ERROR
org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse
Posted by Sven Meier <sv...@meiers.net>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org