Thanks everyone! As I am not ready to switch to Jakarta EE just yet, I went back to Jetty 10 and it seems that, for now, all my issues have disappeared.
I’ll inevitably revisit the subject once I upgrade to Wicket 10 😊 Kind regards, Martin Von: Martin Grigorov <mgrigo...@apache.org> Datum: Dienstag, 23. Januar 2024 um 10:05 An: users@wicket.apache.org <users@wicket.apache.org> Betreff: Re: Wicket 9 + Jetty 12: Lots of exceptions due to modification of read-only response https://issues.apache.org/jira/browse/WICKET-7075 I will backport it to 9.x ! On Tue, Jan 23, 2024 at 10:26 AM Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > On Mon, Jan 22, 2024 at 6:09 PM Martin Simons <martin@simulogics.games> > 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. >> > > Are you still able to deploy to Tomcat ? If YES then it would be good to > check whether your app will experience the same errors there too! > > >> >> 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. >> > > COOP and COEP are new in Wicket 9.x, so it is quite possible that they > might have issues with HEAD requests. > Please provide failing unit tests and/or a quickstart and/or at least > stacktraces! > > >> >> 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. > > > RequestCycle[Listener]#onEndRequest() is called before > HttpServletResponse#flush(), so it shouldn't be that late. But I need to > debug the app to tell whether the response is buffering or not. > See org.apache.wicket.protocol.http.HeaderBufferingWebResponse > > > If you were using Wicket 10.x + servlet-api 6.x then you could use > https://jakarta.ee/specifications/servlet/6.0/apidocs/jakarta.servlet/jakarta/servlet/http/httpservletresponse#setTrailerFields(java.util.function.Supplier) > > > > >> >> 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 >> >
