WIP: [AMQ-9359] Jetty-12 conversion

[mattrpav]

TODO:

• Compile fixes
• Fix web-demo compile issue with InputStreamContentProvider
• Fix/Refactor JspConfigurer to use Handler.Sequence
• Unit test compile fixes
• activemq-http WebSocket client tests failing
• Refactor all jetty.xml's to support updated class package locations

[jbonofre]

I'm already working on this for 6.2./6.3.x.

[cshannon]

Is there any reason not to bump to Java EE 10? Jetty 12.x can run multiple EE versions simultaneously so there's not really a reason to not just go to Servlet 6.0 and Jakarta EE 10 that I can think of. A user that depends on embedded Jetty and AMQ wants to use EE9 for other servlets could still include those jars and be compatible.

[mattrpav]

I think EE10 makes more sense. However, if we jump straight to EE10, I think we’d need to rev to 7.x.

Staying with EE9 would allow us to get to Jetty 12 in 6.x minor release

[cshannon]

I think EE10 makes more sense. However, if we jump straight to EE10, I think we’d need to rev to 7.x.

Staying with EE9 would allow us to get to Jetty 12 in 6.x minor release

Looking at it in more detail and reading https://jetty.org/docs/jetty/12/operations-guide/deploy/index.html , I don't think it's compatible after all for EE9 and EE10 when embedded.

EE10 removes some stuff from the API and i took a look at the Jetty 12 download and they actually package all 3 versions of both the API and modules separately (EE8, EE9, EE10) and each war file is isolated for deployment so you can run independently. This of course does not work for something embedded.

So we can probably stick with EE9 until 7.x. I guess if someone wants to use EE10 and with an embedded version of AMQ they could probably still do so as long as they were not using anything that relied on the EE9 stuff (any of the AMQ websockets or servlets, etc) and they would have to exclude the EE9 transitive dependencies from AMQ

[mattrpav]

So we can probably stick with EE9 until 7.x. I guess if someone wants to use EE10 and with an embedded version of AMQ they could probably still do so as long as they were not using anything that relied on the EE9 stuff (any of the AMQ websockets or servlets, etc) and they would have to exclude the EE9 transitive dependencies from AMQ

If users embed, they should be able to do EE10 runtime by excluding activemq-http and activemq-web-* modules. I believe the other EE specs in use are forward compatible b/w EE9 and EE10.