The useSlf4j2x flag is changed to be more precise and check if the Logger instance actually supports slf4j2 methods, as opposed to checking if slf4j2 exists in the classpath which fails with a slf4j1 logger in a slf4j2 classpath.
A test project exists to demonstrate this issue. It does not pass with the old code, but does pass with this PR's code. I will note it was difficult as hell to reproduce in a vacuum.
Gradle overrides most of the slf4j classes, but it overrides it with a slf4j1 API, which doesn't support slf4j2 methods. This means if you tried to run the AWS SDK for Kotlin in a Gradle buildscript, it would use Gradle's slf4fj1 logger, and the AWS SDK was probably pulling slf4j2 itself into the classpath, causing this problem.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
The
useSlf4j2x
flag is changed to be more precise and check if theLogger
instance actually supports slf4j2 methods, as opposed to checking if slf4j2 exists in the classpath which fails with a slf4j1 logger in a slf4j2 classpath.A test project exists to demonstrate this issue. It does not pass with the old code, but does pass with this PR's code. I will note it was difficult as hell to reproduce in a vacuum.
Issue \
https://github.com/awslabs/aws-sdk-kotlin/issues/1077
Description of changes
Gradle overrides most of the slf4j classes, but it overrides it with a slf4j1 API, which doesn't support slf4j2 methods. This means if you tried to run the AWS SDK for Kotlin in a Gradle buildscript, it would use Gradle's slf4fj1 logger, and the AWS SDK was probably pulling slf4j2 itself into the classpath, causing this problem.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.