Verifies the integrety of the projects, as builds are executed immediately after a code change was detected. This plan provides no artifiacts (use a nightly build instead).

Build result summary

Details

Completed
Queue duration
< 1 second
Duration
12 minutes
Labels
None
Agent
Default Agent
Revision
beed6c8456458de9bb62a4a020d4b79e4ef91a2d
Total tests
1342
Successful since
#2419 ()

Tests

Code commits

Author Commit Message Commit date
Matthew Vivian <matthew.vivian@surevine.com> Matthew Vivian <matthew.vivian@surevine.com> beed6c8456458de9bb62a4a020d4b79e4ef91a2d Bump Jetty patch version to latest on 10
Matthew Vivian <matthew.vivian@surevine.com> Matthew Vivian <matthew.vivian@surevine.com> f8e0278e87afe40020e6389555f330e5247f0c45 WIP: Upgrades Jetty 9.4.43.v20210629 to 10.0.15
Correct configuration of websocket compression. Compression is provided out of the box by Jetty's `permessage-deflate` extension.

Previously Openfire was registering the `permessage-deflate` extension, I assume this was attempting to enable websocket compression.

Presently, websocket compression is enabled by default in Jetty. So the correct way to control websocket compression is to disable the `permessage-deflate` extension when compression is not wanted:
https://github.com/eclipse/jetty.project/issues/1341
Guus der Kinderen Guus der Kinderen 50aeb542aa9c35398944219ec7e851bc3e1fdbd3 WIP: Fix JSP compilation failure in Jetty 10.0.15
In this commit, the taglib definitions are consolidated in one place, where Jetty 10.0.5 expects to find them.

A nuisance is that with this layout, the IntelliJ IDE is no longer able to find the taglibs. This can be annoying during development, but does not introduce runtime issues.
Matthew Vivian <matthew.vivian@surevine.com> Matthew Vivian <matthew.vivian@surevine.com> 09c12d205676431336236da4281596f02681c7ff WIP: Upgrades Jetty 9.4.43.v20210629 to 10.0.15
Remaining Issues:
- JSP compilation failure caused by:

https://github.com/apache/tomcat/commit/224fb6c06528180213b6af28b28dee44029565d7#diff-ef02fd9c3f90ca4838d3cdaa051489556eca75d537fc396022e0ed456c24d895R329

- `WebSocketClientConnectionHandler.onConnect` assumes that `session.getRemoteAddress()` supplies an `InetSocketAddress` which might not always be true. What's the best approach in our context?

Fixed in this commit:
- Websocket server Maven artifact renamed from `websocket-server` to `websocket-jetty-server`
- `WebSocketServlet` renamed to `JettyWebSocketServlet`
- `WebSocketServletFactory` renamed to `JettyWebSocketServletFactory`

See: https://www.eclipse.org/jetty/documentation/jetty-10/programming-guide/index.html#pg-migration-94-to-10

- `GzipHandler` is no longer part of `ServletContextHandler`
https://github.com/eclipse/jetty.project/issues/4765

- Renamed `setWebInfClassesDirs` to `setWebInfClassesResources`
https://github.com/eclipse/jetty.project/issues/4506

- Split `SslContextFactory` into Client and Server
https://github.com/eclipse/jetty.project/issues/3464
Matthew Vivian <matthew.vivian@surevine.com> Matthew Vivian <matthew.vivian@surevine.com> aad09e6950661458654cdb1eca44d3c7c25b9177 Removed WebAppLoaderFix as it is now redundant
Thanks to GregDThomas for spotting: IIRC it only worked on older versions of JRE/Jetty, so it's probably long redundant now.

Originally created to fix https://igniterealtime.atlassian.net/browse/OF-1522 in #1228
(with comment "Note; we may need to revisit this come Java 9.")

Jira issues

IssueDescriptionStatus
Unknown Issue TypeOF-1522Could not obtain issue details from Jira