Re: Exception (Header was already written to response!) when setting response page in IRequestCycleListener

2012-02-27 Thread Martin Grigorov
Hi,

On Sat, Feb 25, 2012 at 12:20 AM, Neil Curzon neil.cur...@gmail.com wrote:
 Hi all,

 We've been using an IRequestCycleListener in order to redirect to a certain
 page for all requests if certain conditions are met. We're finding that
 it's giving an exception in 1.5.4:

 java.lang.IllegalStateException: Header was already written to response!
 at
 org.apache.wicket.protocol.http.HeaderBufferingWebResponse.checkHeader(HeaderBufferingWebResponse.java:64)
 at
 org.apache.wicket.protocol.http.HeaderBufferingWebResponse.setDateHeader(HeaderBufferingWebResponse.java:134)
 at
 org.apache.wicket.protocol.http.BufferedWebResponse$SetDateHeaderAction.invoke(BufferedWebResponse.java:310)
 at
 org.apache.wicket.protocol.http.BufferedWebResponse.writeTo(BufferedWebResponse.java:580)
 at
 org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:185)
 at
 org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
 at
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)

 basically in our IRequestCycleListener we have

 @Override
 public void onBeginRequest(RequestCycle cycle) {
 if (condition)) {
 cycle.setResponsePage(SpecificPage.class);

better use: throw new RestartResponseException()

this will both save you some CPU cycles and additionally will reset
the WebResponse (drop any set headers and body)

 }
 }

 Is this the wrong way to do it? Or is this behavior expected? If it's not
 expected, I will file a bug for this.

 Thanks,
 Neil



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Exception (Header was already written to response!) when setting response page in IRequestCycleListener

2012-02-27 Thread Neil Curzon
Hi Martin,

Sorry, should have mentioned that I also tried doing that. The result is
the orange exception page with Unexpected Runtime Exception:

Last cause: null

Stacktrace

Root cause:

org.apache.wicket.RestartResponseException

Thanks,
Neil

On Mon, Feb 27, 2012 at 11:01 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 On Sat, Feb 25, 2012 at 12:20 AM, Neil Curzon neil.cur...@gmail.com
 wrote:
  Hi all,
 
  We've been using an IRequestCycleListener in order to redirect to a
 certain
  page for all requests if certain conditions are met. We're finding that
  it's giving an exception in 1.5.4:
 
  java.lang.IllegalStateException: Header was already written to response!
  at
 
 org.apache.wicket.protocol.http.HeaderBufferingWebResponse.checkHeader(HeaderBufferingWebResponse.java:64)
  at
 
 org.apache.wicket.protocol.http.HeaderBufferingWebResponse.setDateHeader(HeaderBufferingWebResponse.java:134)
  at
 
 org.apache.wicket.protocol.http.BufferedWebResponse$SetDateHeaderAction.invoke(BufferedWebResponse.java:310)
  at
 
 org.apache.wicket.protocol.http.BufferedWebResponse.writeTo(BufferedWebResponse.java:580)
  at
 
 org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:185)
  at
 
 org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
  at
 
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)
 
  basically in our IRequestCycleListener we have
 
  @Override
  public void onBeginRequest(RequestCycle cycle) {
  if (condition)) {
  cycle.setResponsePage(SpecificPage.class);

 better use: throw new RestartResponseException()

 this will both save you some CPU cycles and additionally will reset
 the WebResponse (drop any set headers and body)

  }
  }
 
  Is this the wrong way to do it? Or is this behavior expected? If it's not
  expected, I will file a bug for this.
 
  Thanks,
  Neil



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Exception (Header was already written to response!) when setting response page in IRequestCycleListener

2012-02-26 Thread nhsoft.yhw
I have the same problem, but only in IE browser, firefox or chrome works 

-
first wicket application: 114生活网 
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Exception-Header-was-already-written-to-response-when-setting-response-page-in-IRequestCycleListener-tp4418783p4422044.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Exception (Header was already written to response!) when setting response page in IRequestCycleListener

2012-02-24 Thread Neil Curzon
Hi all,

We've been using an IRequestCycleListener in order to redirect to a certain
page for all requests if certain conditions are met. We're finding that
it's giving an exception in 1.5.4:

java.lang.IllegalStateException: Header was already written to response!
at
org.apache.wicket.protocol.http.HeaderBufferingWebResponse.checkHeader(HeaderBufferingWebResponse.java:64)
at
org.apache.wicket.protocol.http.HeaderBufferingWebResponse.setDateHeader(HeaderBufferingWebResponse.java:134)
at
org.apache.wicket.protocol.http.BufferedWebResponse$SetDateHeaderAction.invoke(BufferedWebResponse.java:310)
at
org.apache.wicket.protocol.http.BufferedWebResponse.writeTo(BufferedWebResponse.java:580)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:185)
at
org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)

basically in our IRequestCycleListener we have

@Override
public void onBeginRequest(RequestCycle cycle) {
if (condition)) {
cycle.setResponsePage(SpecificPage.class);
}
}

Is this the wrong way to do it? Or is this behavior expected? If it's not
expected, I will file a bug for this.

Thanks,
Neil