Repository navigation
Fix GraalVM native build error caused by stale substitution target in v8.x - #601
Conversation
|
Thanks for the contribution! If you haven't done so it is usually better to discuss your intentions either by opening a new issue or in our slack channel. |
…n to check if target class exists Agent-Logs-Url: https://github.com/oshai/kotlin-logging/sessions/728f006b-d368-4f73-92f3-ca9855e1798f Co-authored-by: oshai <2683969+oshai@users.noreply.github.com>
…oggingConfiguration Agent-Logs-Url: https://github.com/oshai/kotlin-logging/sessions/fb12ce1d-eadb-48ae-8d8f-8cf8962c1db4 Co-authored-by: oshai <2683969+oshai@users.noreply.github.com>
Fixed in 5b822c2 — the substitution now correctly targets |
There was a problem hiding this comment.
Pull request overview
This PR updates the JVM-side GraalVM substitution used by kotlin-logging’s native-image support so it targets the v8.x logger-detection implementation in KotlinLoggingConfiguration instead of the removed internal KLoggerFactory target.
Changes:
- Renames the Graal substitution class/file to match the new v8.x target naming.
- Retargets
@TargetClassfrom the removed internal factory toio.github.oshai.kotlinlogging.KotlinLoggingConfiguration. - Replaces the old substituted logger-construction method with a substitution for
detectLogger()that avoids the Logback path when Logback is absent.
Comments suppressed due to low confidence (1)
src/jvmMain/kotlin/io/github/oshai/kotlinlogging/internal/Target_io_github_oshai_kotlinlogging_KotlinLoggingConfiguration.kt:33
- This substitution no longer preserves the JVM
detectLogger()behavior for thekotlin-logging-to-direct=trueoverride. In native images built without Logback, that property will now be ignored andloggerFactorywill fall back to SLF4J, which breaks the documented way to opt intoDirectLoggerFactoryon JVM.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
In v8.x,
io.github.oshai.kotlinlogging.internal.KLoggerFactorywas moved toio.github.oshai.kotlinlogging.KotlinLoggingConfiguration, but the GraalVM@TargetClasssubstitution still referenced the old internal class. When Logback is absent from the native image classpath, theonlyWithcondition activates the substitution — which then fails because the target class no longer exists at that location.Changes
Target_io_github_oshai_kotlinlogging_internal_KLoggerFactory.kt→Target_io_github_oshai_kotlinlogging_KotlinLoggingConfiguration.kt(following theTarget_naming convention)@TargetClassto target"io.github.oshai.kotlinlogging.KotlinLoggingConfiguration"(the v8.x home of the logger factory detection logic)logger$kotlin_logging(name: String): KLoggertodetectLogger(): KLoggerFactory— the method inKotlinLoggingConfigurationthat referencesLogbackLoggerFactoryand needs to be bypassed when Logback is not on the classpathLogbackNotOnClasspathcondition — since the target class now correctly exists in v8.x, no extra class-existence check is neededThis ensures GraalVM substitutes the correct method in the correct class, preventing native image build failures when Logback is absent from the classpath.