pedestal

2024-08-16T10:06:59.518069Z

Jetty 12 – Pedestal 0.7.0 adopted Jetty 11 supporting Servlet 5.0 with a minimum requirement of Java 11 LTS. We’ve noticed that Jetty 11 actually had https://jetty.org/download.html as of January this year. It will continue to get security fixes for the foreseeable future. They recommend upgrading to Jetty 12, which requires Java 17 LTS. Below is a patch for adding jetty-12 support on top of Pedestal 0.7.0, specifically for the ee10 Servlet 6 environment. It passes the tests. It still uses Pedestal’s servlet support and does not adopt new jetty handlers. We’re currently running this in prod for an internal app. I understand if Pedestal keeps Jetty 11 as default. That said, any interest in considering adding official support for Jetty 12? Since the changes are isolated to the pedestal.jetty module, I’m thinking perhaps adding it as a separate pedestal.jetty-12-ee10 module. Pedestal users could then choose between the two Jetty modules.

👍 1
2024-08-16T10:09:06.195099Z

https://github.com/terjesb/pedestal/tree/jetty-12-ee10

VERSION.txt                                     |  2 +-
 jetty/deps.edn                                  | 10 +++++-----
 jetty/src/io/pedestal/http/jetty.clj            |  7 ++++---
 jetty/src/io/pedestal/http/jetty/container.clj  |  9 ++++-----
 jetty/src/io/pedestal/http/jetty/util.clj       |  3 +--
 tests/deps.edn                                  |  2 +-
 tests/test/io/pedestal/http/jetty_test.clj      |  6 ++----
 tests/test/io/pedestal/http/jetty_util_test.clj |  4 ++--
 8 files changed, 20 insertions(+), 23 deletions(-)

quan xing 2024-08-16T11:02:48.864399Z

I think the idea of providing a separate pedestal.jetty-12-ee10 module is good

quan xing 2024-08-16T11:09:04.875389Z

I am currently still using version 0.5.10 in the production environment

hlship 2024-08-16T15:49:58.738889Z

HttpKit would also be a nice engine to add to the roster.

2024-08-16T15:55:12.782259Z

@terjesb regarding the choice to continue using the Servlet API instead of the new alternative Jetty "handlers", - do you expect "handlers" would bring benefits? The page https://jetty.org/docs/jetty/12/programming-guide/server/http.html mentions "normal classloading behavior" (in addition to other differences that I suspect are not meaningful in the context of Pedestal, Ring, and Clojure). Are we disturbed by servlet classloading?

2024-08-19T16:26:57.643059Z

As an alternative to the previous patch, I’ve added a preliminary PR for pedestal.jetty-12-ee10 in https://github.com/pedestal/pedestal/pull/866 for discussion. The current tests included Jetty 11 by default. Moved this into a separate :jetty-11 alias. Tests now run via clj -T:tests run instead of clj -X:test, which then runs:

clojure -X:jetty-11:test :dirs '["test" "test-jetty-11"]'
clojure -X:jetty-12-ee10:test :dirs '["test" "test-jetty-12-ee10"]'
Not at all sure this is the best way of doing this? (All the non-Jetty tests are now run twice.) As to continue with Servlet API, for now just to get (preliminary?) Jetty 12 support with minimal changes and to support common Servlet API. I would expect native Jetty handlers to have less overhead and thus be even faster. Haven’t checked impact on Pedestal APIs. When/if looking into a http-kit module, maybe it would make sense to consider Jetty 12 handlers at the same time.