Closed Invertisment closed 1 year ago
Thanks for the report. A PR to fix this would be welcome.
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.
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.
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.
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.
Thanks for the investigation and verifying it works with 1.9.1. I hope you find the cause of your issue.
The commit https://github.com/ring-clojure/ring/commit/cb28ec5a0897f67cd653657141b752a52f19e0fd introcuces a new import of
KeyStoreScanner
into the namespace. That class hasLOG
instance which can be seen here: https://github.com/eclipse/jetty.project/blob/cb127793e5d8b5c5730b964392a9a905ba49191d/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/KeyStoreScanner.java#L39This log instance is initialized at build time and this message is printed when I run
ring uberjar
on my Clojure app:The timestamp
15339ms
is the time since the JVM has started and doesn't say much but what it does it initialize the logging at build time.And this logging initialization prevents me from running graalvm's
native-image
command because this message appears:That means that by requring namespace
ring.adapter.jetty
in any way (I tried to requirerun-jetty
and:as
but it still loads that class which I don't use at all (because my SSL is managed by my cloud provider)) I can't build graalvm executable. My version:[ring/ring-jetty-adapter "1.9.5"]