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: #2436 was successful

Job: Build was successful

Stages & jobs

  1. Default Stage

Code commits

Openfire (master)

  • Matthew Vivian <matthew.vivian@surevine.com>

    Matthew Vivian <matthew.vivian@surevine.com> beed6c8456458de9bb62a4a020d4b79e4ef91a2d

    Bump Jetty patch version to latest on 10

    • plugins/pom.xml (version beed6c8456458de9bb62a4a020d4b79e4ef91a2d)
    • pom.xml (version beed6c8456458de9bb62a4a020d4b79e4ef91a2d)
  • 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

    • xmppserver/src/main/java/org/jivesoftware/openfire/websocket/OpenfireWebSocketServlet.java (version f8e0278e87afe40020e6389555f330e5247f0c45)
  • 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.

    • xmppserver/src/main/resources/META-INF/admin.tld (version 50aeb542aa9c35398944219ec7e851bc3e1fdbd3)
    • xmppserver/src/main/webapp/META-INF/tags/admin/contentBox.tagx (version 50aeb542aa9c35398944219ec7e851bc3e1fdbd3)
    • xmppserver/src/main/webapp/META-INF/tags/admin/infoBox.tagx (version 50aeb542aa9c35398944219ec7e851bc3e1fdbd3)
    • xmppserver/src/main/webapp/WEB-INF/admin.tld (version 50aeb542aa9c35398944219ec7e851bc3e1fdbd3)
    • xmppserver/src/main/webapp/WEB-INF/classes/META-INF/admin.tld (version 50aeb542aa9c35398944219ec7e851bc3e1fdbd3)
    • xmppserver/src/main/webapp/WEB-INF/classes/META-INF/tags/admin/contentBox.tagx (version 50aeb542aa9c35398944219ec7e851bc3e1fdbd3)
    • xmppserver/src/main/webapp/WEB-INF/classes/META-INF/tags/admin/infoBox.tagx (version 50aeb542aa9c35398944219ec7e851bc3e1fdbd3)
    • xmppserver/src/main/webapp/WEB-INF/classes/META-INF/tags/admin/security/identityStoreConfig.tagx (version 50aeb542aa9c35398944219ec7e851bc3e1fdbd3)
    • xmppserver/src/main/webapp/WEB-INF/classes/META-INF/tags/admin/security/trustStoreConfig.tagx (version 50aeb542aa9c35398944219ec7e851bc3e1fdbd3)
  • 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

    • plugins/pom.xml (version 09c12d205676431336236da4281596f02681c7ff)
    • pom.xml (version 09c12d205676431336236da4281596f02681c7ff)
    • xmppserver/pom.xml (version 09c12d205676431336236da4281596f02681c7ff)
    • xmppserver/src/main/java/org/jivesoftware/openfire/container/AdminConsolePlugin.java (version 09c12d205676431336236da4281596f02681c7ff)
    • xmppserver/src/main/java/org/jivesoftware/openfire/container/PluginServletContext.java (version 09c12d205676431336236da4281596f02681c7ff)
    • xmppserver/src/main/java/org/jivesoftware/openfire/http/HttpBindManager.java (version 09c12d205676431336236da4281596f02681c7ff)
    • xmppserver/src/main/java/org/jivesoftware/openfire/spi/EncryptionArtifactFactory.java (version 09c12d205676431336236da4281596f02681c7ff)
    • xmppserver/src/main/java/org/jivesoftware/openfire/websocket/OpenfireWebSocketServlet.java (version 09c12d205676431336236da4281596f02681c7ff)
    • xmppserver/src/main/java/org/jivesoftware/openfire/websocket/WebSocketClientConnectionHandler.java (version 09c12d205676431336236da4281596f02681c7ff)
  • 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.")

    • xmppserver/src/main/java/org/eclipse/jetty/util/WebAppLoaderFix.java (version aad09e6950661458654cdb1eca44d3c7c25b9177)
    • xmppserver/src/main/java/org/jivesoftware/openfire/http/HttpBindManager.java (version aad09e6950661458654cdb1eca44d3c7c25b9177)
  • Matthew Vivian <matthew.vivian@surevine.com>

    Matthew Vivian <matthew.vivian@surevine.com> 42d7cf52146e11d5db21820ca4e22cd8f3880456

    WIP: Upgrades Jetty 9.4.43.v20210629 to 10.0.15
    Fix to initialise web socket components.

    With Jetty 10 we now need to configure the WebSocket ServletContextHandler to call the JettyWebSocketServletContainerInitializer during the ServletContext initialization phase.

    • xmppserver/src/main/java/org/jivesoftware/openfire/http/HttpBindManager.java (version 42d7cf52146e11d5db21820ca4e22cd8f3880456)
  • Guus der Kinderen

    Guus der Kinderen 0a3ef02ae1ccd93278785013741b0fc04cdea481

    WIP: Fix classloading issue in Jetty 10.0.15
    With Jetty 10.0.15, the admin console shows HTTP 503 error responses, and ClassLoading exceptions are logged.

    It appears that in Jetty 10, unless a ClassLoader has been explicitly set on a ContextHandler, Jetty will use its own implementation. I assume (but did not check) that in Jetty 9, this was different (possibly, it used the ClassLoader of the invoking thread?). The ClassLoader that is provided by Jetty cannot find most of the libraries in the way they are provided by Openfire.

    Openfire uses its own ClassLoaders. When Jetty's embedded server is instantiated to use the ClassLoader of the invoking thread as done in this commit, then the problem disappears.

    Questions remain:
    - Why does Jetty use their own ClassLoader (unless explicitly overridden)? This suggests that this is somehow important (which this change has undone - which might not be safe).
    - Is there a better way of doing this? Maybe use a different ClassLoader instance, or somehow configure the Jetty classloader to find the classes it needs?
    - Will this work with plugins?
    - Do we need to do this elsewhere (eg: everywhere a Jetty Server is instantiated?)

    • xmppserver/src/main/java/org/jivesoftware/openfire/container/AdminConsolePlugin.java (version 0a3ef02ae1ccd93278785013741b0fc04cdea481)