Upgrading to 0.29.0-Beta introduces slf4j dependency hell: NoSuchMethodError #993
Comments
mgroth0
added
bug
|
I am testing |
|
Thanks for the issue. Indeed in
I can provide some suggestions perhaps but it doesn't really look like an issue with the SDK, it's an issue with your classpath + gradle. |
aajtodd
added
response-requested
|
@aajtodd Thanks for the response and for the offer to provide some advice. Sorry my original issue was so messy. I did not even want to try to make a reproducer because my project was so complex. But I did actually just try now, and luckily I was wrong. It was actually very simple and easy to reproduce! https://github.com/mgroth0/aws-slf4j-dep-hell There it is. If you clone and try to run any gradle command there, you should hopefully see the error. |
github-actions
bot
removed
the
response-requested
|
@aajtodd I am running into the same issue after upgrading to |
|
@sdhuka somewhere in your dependency closure slf4j 1.x is being pulled in. Your options are:
(1) is maybe the quickest route (assuming there is a solution). We plan on doing (2) anyway at some point but it wasn't on our roadmap yet. |
|
It seems gradle it self is introducing the dependency ? gradle/gradle#26348 We're hit with #905 because we upload a jar for signing to s3 using the sdk and know we are stuck. I can't update to >= 0.29 until gradle fixes the issue on their side which will take time they say. Any idea on how to move forward? |
|
If you can't figure out a way to correct your classpath to use SLF4J 2.x then you might be able to try excluding the slf4j2 implementation that the default telemetry provider uses and then supplying an implementation based on slf4j 1.x // file: build.gradle.kts
dependencies {
implementation("aws.sdk.kotlin:s3:<version>) {
exclude(group = "aws.smithy.kotlin", module = "logging-slf4j2")
}
}This will require you provide a binding though at the expected location used by the default provider. e.g. You would need to implement a corresponding type using the SLF4j 1.x API at the same import path: // file: your custom 1.x implementation file
package aws.smithy.kotlin.runtime.telemetry.logging.slf4j
/**
* SLF4J 1.x based logger provider
*/
public object Slf4jLoggerProvider : LoggerProvider {
override fun getOrCreateLogger(name: String): Logger {
val sl4fjLogger = LoggerFactory.getLogger(name)
return Slf4JLoggerAdapter(sl4fjLogger)
}
}
private class Slf4jLoggerAdapter(private val delegate: org.slf4j.Logger) : Logger {
// your 1.x adapter code
}Caveat I haven't tested the above but thats the general idea. You strip the SLF4J 2.x implementation and provide a 1.x equivalent at the same import location. JVM class loader would then pickup your implementation at runtime. We may provide a 1.x binding directly one day but the default will remain 2.x so you would still have to do some work in your build script to exclude dependencies and swap them. |
|
If anyone has a working example of the above I would love to see it. |
|
|
This should be fixed starting in 0.32.3-beta. If you continue to encounter issues please open a new issue. |
Describe the bug
I'm using the sdk in gradle. That is, in a gradle "plugin" that shares a classpath with the Gradle API. Things were fine before, but suddenly after the new update I'm getting a NoSuchMethodError.
Expected behavior
No error
Current behavior
On an sdk method call, I get the following:
Steps to Reproduce
Creating a perfect reproducer seems very time consuming since it involves getting all the dependencies and build logic right. But essentially, it might be something like:
settings.gradle.kts, load this folder of jars like so:buildscript { dependencies { compile(fileTree(jarFolder)) } }Possible Solution
I'm not sure if the reproduction steps above would work, because its a sort of complex environment that I have and something might be missing. But in any case, I was able to figure out a few things while I was trying to debug this.
First of all, I added this to my code immediately before calling the sdk:
kotlin
The output of that is:
This is interesting. Note the following:
slf4j-api-2.0.6is in fact added as a compile dependency in my settings.gradle.kts right next to the sdk.isEnabledForLevelis in fact only present inslf4j 2.x.slf4j-nopto the classpath, but this did not help.Loggerclass from its own internalslf4j 1.xjar before I even add the sdk.At a bare minimum, having a way to disable logging completely to dodge this error in the meantime while a more robuse solution is eventually implemented would be great.
Context
Gradle Version: 8.2.1
Kotlin Version: 1.9.0
I was in sort of desperate need for the new update, because I kept running into #905
The above issue does have a workaround. I have implemented custom retry logic, which mostly works. But even this is failing sometimes. I'm very eager to try the solution that was seemingly implemented in 0.29.0
When I downgrade back to 0.28.0-beta, I dodge the slf4j dependency hell issue, but re-introduce the old
java.io.EOFException: \n not found: limit=0 content=…from the above referenced issue.AWS Kotlin SDK version used
0.29.0-beta
Platform (JVM/JS/Native)
JVM
Operating System and version
Mac
The text was updated successfully, but these errors were encountered: