Re: Wicket 9 + Jetty 12: Lots of exceptions due to modification of read-only response

[Maxim Solodovnik]

Hello Martin,

On Mon, 22 Jan 2024 at 23:09, Martin Simons  wrote:
>
> Hey everyone,
>
> I started a gnarly migration of a really old Wicket 6 application to Wicket 9 
> last week. One of the objectives was to move away from a .war-based 
> deployment to a Tomcat app server, and instead go with an embedded server 
> which runs within a Docker file. The choice here fell on Jetty 12 using the 
> EE8 environment.

I believe you need Wicket10 for Jetty12 :)

>
> So far, so good. After getting all the API changes sorted out, most things 
> work as expected. But what puzzles me is that I get the logs flooded with 
> exceptions because different pieces of code try to write to the web response 
> at a point in the web request cycle when it has already been committed.
>
> For Wicket itself, this affects the COOP and COEP filters when handling HEAD 
> requests.
>
> My one code is affected (for example) when trying to set a cookie at the end 
> of a request cycle.
>
> So two questions:
>
>   1.  I am likely missing something obvious. Does anyone see what it might be?
>   2.  Regarding my own code: I get that I can’t write to a response that’s 
> been committed, but what’s “the Wicket way” to modify a response header after 
> the response has been processed but before it is written? 
> RequestCycleListener::onEndRequest() seems to be too late.
>
> I found surprisingly little on this problem when googling, so I am almost 
> certain it’s my mistake. But after looking at it for days, I am sort of 
> stuck. I would greatly appreciate a few pointers.
>
> Thank you very much,
> Martin



-- 
Best regards,
Maxim

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

Wicket 9 + Jetty 12: Lots of exceptions due to modification of read-only response

[Martin Simons]

Hey everyone,

I started a gnarly migration of a really old Wicket 6 application to Wicket 9 
last week. One of the objectives was to move away from a .war-based deployment 
to a Tomcat app server, and instead go with an embedded server which runs 
within a Docker file. The choice here fell on Jetty 12 using the EE8 
environment.

So far, so good. After getting all the API changes sorted out, most things work 
as expected. But what puzzles me is that I get the logs flooded with exceptions 
because different pieces of code try to write to the web response at a point in 
the web request cycle when it has already been committed.

For Wicket itself, this affects the COOP and COEP filters when handling HEAD 
requests.

My one code is affected (for example) when trying to set a cookie at the end of 
a request cycle.

So two questions:

  1.  I am likely missing something obvious. Does anyone see what it might be?
  2.  Regarding my own code: I get that I can’t write to a response that’s been 
committed, but what’s “the Wicket way” to modify a response header after the 
response has been processed but before it is written? 
RequestCycleListener::onEndRequest() seems to be too late.

I found surprisingly little on this problem when googling, so I am almost 
certain it’s my mistake. But after looking at it for days, I am sort of stuck. 
I would greatly appreciate a few pointers.

Thank you very much,
Martin