Hi Sven, Well that might explain a lot then!
We hired someone to do the migration from wicket 1.4 to 6 for us as we didn't have time or the expertise with the latest version. Previously we used : getRequestCycle().setRequestTarget(new RedirectRequestTarget()) and the consultant replaced that everywhere with: getRequestCycle().scheduleRequestHandlerAfterCurrent(new RedirectRequestHandler()) I will test with RedirectToUrlException On Wed, Nov 19, 2014 at 1:02 PM, Sven Meier <[email protected]> wrote: > Hi, > > I'm not exactly sure what you're trying to do, but the following is just > wrong: > > getRequestCycle().scheduleRequestHandlerAfterCurrent(new > RedirectRequestHandler("http://localhost:8080/wicket/ > bookmarkable/com.mycompany.Foo2?ff=gg")); > > This will result in two responses written to the client, one redirect to > the currently requested page and one to the url you have provided. > > Why aren't you using a RedirectToUrlException? > > Regards > Sven > > > > On 11/18/2014 08:35 PM, Wayne W wrote: > >> Hi Sven, >> >> Kind of - however its seems to happen only in 6.17. In 6.18 it seems to >> work ok with the quick start, but with our code base it still happens even >> with 6.18. I see this fix https://issues.apache.org/ >> jira/browse/WICKET-5689 >> which seems somewhat related (nested redirects). Its still very odd that >> just changing the setPageRendererProvider would change the behaviour. >> >> For you reference here is the quick start can be found here: >> >> https://customerservices.glasscubes.com/share/s/dvkg92u54 >> >> >> It produces this: >> >> WARN - ServletHandler - / >> >> java.lang.IllegalStateException: Committed >> >> at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1141) >> >> at org.eclipse.jetty.server.Response.sendRedirect(Response.java:493) >> >> at org.apache.wicket.protocol.http.servlet.ServletWebResponse. >> sendRedirect( >> ServletWebResponse.java:297) >> >> at >> org.apache.wicket.protocol.http.BufferedWebResponse$ >> SendRedirectAction.invoke( >> BufferedWebResponse.java:400) >> >> at org.apache.wicket.protocol.http.BufferedWebResponse.writeTo( >> BufferedWebResponse.java:588) >> >> at org.apache.wicket.protocol.http.HeaderBufferingWebResponse. >> stopBuffering( >> HeaderBufferingWebResponse.java:60) >> >> at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush( >> HeaderBufferingWebResponse.java:97) >> >> at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle( >> WicketFilter.java:269) >> >> at org.apache.wicket.protocol.http.WicketFilter.processRequest( >> WicketFilter.java:201) >> >> at org.apache.wicket.protocol.http.WicketFilter.doFilter( >> WicketFilter.java:282) >> >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter( >> ServletHandler.java:1291) >> >> at org.eclipse.jetty.servlet.ServletHandler.doHandle( >> ServletHandler.java:443 >> ) >> >> at org.eclipse.jetty.server.handler.ScopedHandler.handle( >> ScopedHandler.java:137) >> >> at org.eclipse.jetty.security.SecurityHandler.handle( >> SecurityHandler.java:556) >> >> at org.eclipse.jetty.server.session.SessionHandler.doHandle( >> SessionHandler.java:227) >> >> at org.eclipse.jetty.server.handler.ContextHandler.doHandle( >> ContextHandler.java:1044) >> >> at org.eclipse.jetty.servlet.ServletHandler.doScope( >> ServletHandler.java:372) >> >> at org.eclipse.jetty.server.session.SessionHandler.doScope( >> SessionHandler.java:189) >> >> at org.eclipse.jetty.server.handler.ContextHandler.doScope( >> ContextHandler.java:978) >> >> at org.eclipse.jetty.server.handler.ScopedHandler.handle( >> ScopedHandler.java:135) >> >> at org.eclipse.jetty.server.handler.HandlerWrapper.handle( >> HandlerWrapper.java:116) >> >> at org.eclipse.jetty.server.Server.handle(Server.java:369) >> >> at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest( >> AbstractHttpConnection.java:486) >> >> at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest( >> BlockingHttpConnection.java:53) >> >> at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete( >> AbstractHttpConnection.java:933) >> >> at >> org.eclipse.jetty.server.AbstractHttpConnection$ >> RequestHandler.headerComplete( >> AbstractHttpConnection.java:995) >> >> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) >> >> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) >> >> at org.eclipse.jetty.server.BlockingHttpConnection.handle( >> BlockingHttpConnection.java:72) >> >> at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run( >> SocketConnector.java:264) >> >> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( >> QueuedThreadPool.java:608) >> >> at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run( >> QueuedThreadPool.java:543) >> >> at java.lang.Thread.run(Thread.java:680) >> >> Why in production it produces this is not yet clear but seems related: >> HTTP Status 500 - Cannot call sendRedirect() after the response has been >> committed >> ------------------------------ >> >> *type* Exception report >> >> *message* *Cannot call sendRedirect() after the response has been >> committed* >> >> *description* *The server encountered an internal error that prevented it >> from fulfilling this request.* >> >> *exception* >> >> >> java.lang.IllegalStateException: Cannot call sendRedirect() after the >> response has been committed >> org.apache.catalina.connector.ResponseFacade.sendRedirect( >> ResponseFacade.java:482) >> javax.servlet.http.HttpServletResponseWrapper.sendRedirect( >> HttpServletResponseWrapper.java:137) >> org.apache.wicket.protocol.http.servlet.ServletWebResponse. >> sendRedirect(ServletWebResponse.java:268) >> org.apache.wicket.protocol.http.BufferedWebResponse$ >> SendRedirectAction.invoke(BufferedWebResponse.java:400) >> org.apache.wicket.protocol.http.BufferedWebResponse. >> writeTo(BufferedWebResponse.java:588) >> org.apache.wicket.protocol.http.HeaderBufferingWebResponse. >> stopBuffering(HeaderBufferingWebResponse.java:60) >> org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush( >> HeaderBufferingWebResponse.java:97) >> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle( >> WicketFilter.java:269) >> org.apache.wicket.protocol.http.WicketFilter. >> processRequest(WicketFilter.java:201) >> org.apache.wicket.protocol.http.WicketFilter.doFilter( >> WicketFilter.java:282) >> com.wideplay.warp.persist.PersistenceFilter$3.run( >> PersistenceFilter.java:141) >> com.wideplay.warp.persist.internal.Lifecycles. >> failEarlyAndLeaveNoOneBehind(Lifecycles.java:29) >> com.wideplay.warp.persist.PersistenceFilter.doFilter( >> PersistenceFilter.java:155) >> >> >> On Mon, Nov 17, 2014 at 7:16 PM, Sven Meier <[email protected]> wrote: >> >> Can you reproduce the problem in a quickstart? >>> >>> Sven >>> >>> >>> On 11/17/2014 06:46 PM, Wayne W wrote: >>> >>> Hi, >>>> >>>> We had the requirement that we needed to use >>>> RedirectPolicy.NEVER_REDIRECT for >>>> a single page in our app . >>>> We used this code: >>>> >>>> >>>> setPageRendererProvider(new IPageRendererProvider() { >>>> >>>> @Override >>>> >>>> public PageRenderer get(final RenderPageRequestHandler context) { >>>> >>>> return new WebPageRenderer(context) { >>>> >>>> @Override >>>> >>>> protected RedirectPolicy getRedirectPolicy() { >>>> >>>> RedirectPolicy result; >>>> >>>> if (!((WebRequest) RequestCycle.get().getRequest()).isAjax() >>>> >>>> && context.getPage() instanceof ExternalShareDocumentPage) { >>>> >>>> result = RedirectPolicy.NEVER_REDIRECT; >>>> >>>> } else { >>>> >>>> result = super.getRedirectPolicy(); >>>> >>>> } >>>> >>>> return result; >>>> >>>> } >>>> >>>> }; >>>> >>>> } >>>> >>>> }); >>>> >>>> This seemed to work fine. However we made it live in production and we >>>> noticed that we where getting "HTTP Status 500 - Cannot call >>>> sendRedirect() >>>> after the response has been committed" a lot. It seemed to happen with >>>> a >>>> flow like the following which was nothing to do with the >>>> ExternalShareDocumentPage >>>> tweak: >>>> >>>> User clicks on link which does a setResponcePage(foo1.class) >>>> in the constructor of foo1.class there is: >>>> if (certainCondition) { >>>> >>>> throw new RestartResponseException(foo2.class) >>>> } >>>> >>>> >>>> What I don't understand is why this is happening. It seems that by >>>> setting >>>> the PageRenderProvider the way the redirects/commit seems to change. >>>> Any ideas? >>>> >>>> >>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
