You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Wayne W <wa...@gmail.com> on 2014/11/17 18:46:36 UTC
IPageRendererProvider - HTTP 500 issue
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?
Re: IPageRendererProvider - HTTP 500 issue
Posted by Wayne W <wa...@gmail.com>.
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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: IPageRendererProvider - HTTP 500 issue
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: IPageRendererProvider - HTTP 500 issue
Posted by Wayne W <wa...@gmail.com>.
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 <sv...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: IPageRendererProvider - HTTP 500 issue
Posted by Sven Meier <sv...@meiers.net>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org