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 <s...@meiers.net> 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 <s...@meiers.net> 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: 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
>
>

Reply via email to