Conflict between `ring-jetty9-adapter` and `cognitect/aws-api`

[vkz]

Effects #3 which in our case relies on ring-jetty9-adapter.

Effect: ring-jetty9-adapter with WebSocket support and congintect/aws-api cannot be used in the same project

ring-jetty9-adapter solution works fine, but sadly creates a conflict with cognitect/aws-api. Former, pulls in Jetty v10, while latter depends on cognitect/http-client which needs Jetty v9. These two are incompatible versions with breaking API changes. With Jetty v10, cognitect/http-client throws when attempting to execute the following top-level code (so it breaks whenever attempt is made to even load that namespace):

(ns cognitect.http-client
  ...
  (:import [org.eclipse.jetty.util.log Log]))

...
  (Log/getProperties)
...

Problem is Log in Jetty 10 doesn't even have that method.

There is no way to resolve this conflict, so we either use ring-jetty9-adapter with WebSocket support or congintect/aws-api but not both at the same time in the same project. Sigh.

Two possible solutions here.

1. We implement our own WebSocket support based on Jetty v9
2. We unwrap cognitect/aws-api and make it our own by changing cognitect/http-client to use Jetty v10 API.

To add to confusion cognitect/http-client source is nowhere to be found i.e. not on Github. But you can grab source from the .m2/repositories/com/cognitect/http-client - it is just a single file.

[vkz]

Simplest temp solution could be:

• git submodule com.cognitect.http-client,
• depend on local code and :exclude other mentions of that client from upstream deps,
• remove configure-jetty-announce since that property simply don't exist in Jetty 10,
• see if it continues to work
• fix what broke

Briefly looking at Jetty http-client 9 vs Jetty http-client 10 they may actually be compatible from the user perspective. If I read docs correctly, may be even able to ditch SSL context setup from cognitect http-client, cause Jetty 10 does necessary setup automatically to get HTTPS?

[vkz]

Alternative could be to switch to something like https://github.com/dakrone/clj-http but:

• could be much work to re-create error handling, limits, secrets,
• would add dependency on apache client while we already have Jetty available