Re: ERROR org.apache.wicket.protocol.http.WebApplication.storeBufferedResponse
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.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, 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: 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