Regression: Quarkus Native Build broken in 7.0.3 #465
Comments
|
Thank you for reporting an issue. See the wiki for documentation and slack for questions. |
|
Hi, is this different in any way than slf4j which we also have as a compile only dependency? |
|
Does adding logback to the classpath solves the issue? |
|
Hi @oshai, thanks for the quick reply!
|
|
I am not graal expert but it seems that preventing from class loading other classes like this is the way to fix this: You mentioned it didn’t work though. I wonder if any other code change might have similar effect, Maybe instead of import, loading the class via reflection for example. |
|
I don't know much about the Graal internals either, but I'm guessing that the What surprises me is that the LogbackLoggerFactory shouldn't even be called if the Loading the class via reflection would probably help. It would mean that if you want to use it in a native build, you'd have to May I ask what is the advantage of the explicit logback support anyway? I always thought that logback supports slf4j out of the box, so why this extra wrapper instead of just using it through slf4j? |
There are slight differences in the api between slf4j and logback, you can see #449 for more details. Another suggestion: Can you try configure a reachability handler to avoid loading those classes: Something like this: |
|
I think this would not work - to add such a handler, I would need to have Logback on the classpath (because I need a I wanted to try this approach for the I also build a version of kotlin-logging locally where It works with |
|
I am not sure that for reachability handler you must have the class in classpath, definitely not in the image classpath. See an example from gemini: https://g.co/gemini/share/ab1a595a81a0 |
|
I cannot find anything about that class |
I am using kotlin-logging in a Quarkus application. When upgrading from 7.0.0 to 7.0.3, the native build starts to fail due to logback not being on the class path. The problem was probably introduced with #452. The native build initializes classes eagerly at build time. I tried to fix it with the
--intialize-at-run-timeoption for GraalVM, but could not get it to run.To reproduce, you can create a simple Quarkus application at https://code.quarkus.io/?e=kotlin and add kotlin-logging as a dependency and add a logger to the
GreetingResourceclass. Then build with./mvnw clean package -PnativeThe error message from the native build is:
The text was updated successfully, but these errors were encountered: