AW: Wicket 9 + Jetty 12: Lots of exceptions due to modification of read-only response
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 Datum: Dienstag, 23. Januar 2024 um 10:05 An: 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 wrote: > Hi, > > On Mon, Jan 22, 2024 at 6:09 PM 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. >> > > 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 >> >
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 wrote: > Hi, > > On Mon, Jan 22, 2024 at 6:09 PM 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. >> > > 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 >> >
Re: Wicket 9 + Jetty 12: Lots of exceptions due to modification of read-only response
Hi, On Mon, Jan 22, 2024 at 6:09 PM 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. > 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 >
Re: Wicket 9 + Jetty 12: Lots of exceptions due to modification of read-only response
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
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
