Prevent compilation-time jetty log initialization about ring HOT 6 CLOSED

Thanks for the report. A PR to fix this would be welcome.

from ring.

I found that I can use 1.8.0 version and it compiles fine. But that's not a good workaround.

One fix that I can think of is to split the namespace so that the imports would be located in two separate namespaces and the builder methods would be separated as well.
I think this would require a major version bump (then the non-ssl namespace would be graalvm compilable and the other not).

One alternative to it would be to dynamically load the class by its title when the ssl method is called. But this would mean that if the JAR that contains that class changes then the build will break (but it would be known at build time at least).
Example: https://github.com/clojure/clojure/blob/e6fce5a42ba78fadcde00186c0b0c3cd00f45435/src/clj/clojure/core.clj#L6837

In any way the ssl function is not useful in graalvm because it loads the offending class. Do you think it's a good idea to support graalvm? I reported because I had an issue with it but I don't know what are the goals of this lib.

There could also be a hybrid approach where we would still have two namespaces but we would load the ssl namespace lazily on method call. This way we would be able to keep the current interface but still separate the namespaces. Then eventually the method could be marked with ^:deprecated.

I don't want to remove the functionality because somebody may depend on it (it would be unfortunate if suddenly somebody would find out that their webpage is HTTP-only because some kind of scanner didn't load).

Edit: I thought that ssl-connector is public. I'll make the lazy-namespace PR to review. Or maybe you'll have a better idea.

from ring.

I think supporting GraalVM is a good idea, but if we want to make the support official it'll need tests to prevent regressions from classes like this. I'm fine with lazy loading the offending piece of code, with an eye to looking to add some GraalVM tests in future to prevent this sort of thing from happening in future.

from ring.

My chat with @borkdude showed that I have no idea where the bug is. I tried to create a minimum repro and I think I can't find it. I'll try to import more things.
But on my large project it's consistently not failing with version 1.8.0 and failing with 1.8.1. So I missed something in my repro.

from ring.

I tried with my minimal repro and when I add [com.google.firebase/firebase-admin "8.1.0"] then my minimal repro fails no matter what. So it fails even if it's the only dependency.
But it gets more interesting.
There is version 9.0.0 which doesn't fail on minimal repro and even on the version with all of the other dependencies. But it fails when I use it in my large project.
So um... sorry for wasting time and accusing this project when it's not its fault. But at this point I actually don't really know what fails in my codebase. Something somehow binds together. But probably it's incorrect timing of the logger initialization on the google's side.
But currently I don't know and I'll close this issue. Minimal repro with this project and logger worked alright. So GraalVM works for 1.9.1. So at least somebody verified it.

from ring.

Thanks for the investigation and verifying it works with 1.9.1. I hope you find the cause of your issue.

from ring.