As for using Jetty, I would like it to keep it in our "package" as it is faster than HttpServer (embedded) and Jetty is a proper Servlet API implementation. For embedded HttpServer, I had to write implementation of this API and I'm pretty sure that it is still not complete.

I wonder if, with new VirtualThreads, default HttpServer from JDK wouldn't be sufficient?

I think it should be rather simple just to replace executor scheduler for HttpServer. If I recall correctly, we are already providing current executor so changing it to VirtualThreads-based executor should be rather simple. However, I'm not sure if that will help as I think that accepting connection and basic parsing is still done on a single thread.

Maybe examining lightweight alternatives (like https://github.com/ebarlas/microhttp

If we could find a single alternative that would be compliant with Servlet API, performant and had large community (or at least not small) that I would suggest to replace both Jetty and HttpServer with a single implementation.

At this point, if I would have to decide, I would suggest to merge http-api and http-api-jetty and drop embedded HttpServer (as it was at the begining) and only support Jetty. I know it has dependencies but at least we can relay of HTTP implementation in it and if needed we could simply create a new startup for other HTTP server implementation and just replace it (without a need to reimplement Servlet API as we need for Java embedded HttpServer).

There is also https://undertow.io/ that is quite nice and maybe it has less dependencies that Jetty.

@andrzej.wojcik I second your suggestion.

I suggested using just embedded HttpServer as I recalled you already implemented swaths of ServletAPI so I considered it "complete enough" for the task.

Switching to VirtualThreads should be easy - just switch executor - the question was more about performance as from what I recall you implemented (at least in previous version) fixed pool and it could cause congestion, which should be mitigated with VT.

Alas, if that's not the case then indeed switching to Jetty altogether should be the best way. I check Undertow and it seems "heavier".

@wojtek I've added a deprecation warning to JavaStandaloneHttpServer in 8.5.0. I wonder, if we should merge http-api-jetty with http-api 8.5.0 or wait for 9.0.0? Also, I'm not sure if we cannot remove JavaStandaloneHttpServer in 8.5.0 and need to wait for 9.0.0 as we wouldn't remove whole functionality, we would just replace embedded HTTP server with Jetty and external API (implemented interfaces) would match...

I've added a deprecation warning to JavaStandaloneHttpServer in 8.5.0.

Great.

I wonder, if we should merge http-api-jetty with http-api 8.5.0 or wait for 9.0.0?

I think we could merge it now as it wouldn't affect deployment/configuration/api (same packages/classes).

Ideally git history should be maintained.

Also, I'm not sure if we cannot remove JavaStandaloneHttpServer in 8.5.0 and need to wait for 9.0.0 as we wouldn't remove whole functionality, we would just replace embedded HTTP server with Jetty and external API (implemented interfaces) would match...

While API-wise it's the same, it would not be a "minor, non braking update" for the main Tigase release (i.e. someone would possibly have to adjust the configuration).

Though, while we don't explicitly require configuring the class, if someone had configured it to use JavaStandaloneHttpServer then upgrading would break. I think that for the 8.5 release we should:

• merge repos
• switch default to Jetty
• add deprecation warning during startup (akin to push-fcm)

I've merged HTTP API and HTTP API - Jetty what preserved history. I've also switched default HTTP server to Jetty, added warning about deprecation to embedded HTTP server and updated documentation of HTTP API project.

Looks good.

(I added 'archived' label to https://tigase.dev/tigase/_server/tigase-http-api-jetty)