[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:
Libraries should not depend on an SLF4J binding, as that imposes a specific choice of logging implementation on clients of the library.
Specifically note this paragraph at the end of that section:
Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J's purpose. When you come across an embedded component declaring a compile-time dependency on any SLF4J binding, please take the time to contact the authors of said component/library and kindly ask them to mend their ways.
Expected Behavior
The pom.xml files for the ASK SDK artifacts should depend on slf4j-api, and not log4j-slf4j-impl.
Replace log4j-slf4j-impl dependency with slf4j-api dependency, and let the clients of your library supply the implementation of SLF4J that matches their underlying logging system (log4j v1, log4j v2, Logback, etc.)
Context
We use log4j v1, and provide the log4j v1 SLF4J implementation (slf4j-log4j12) in our classpath, but because of the ASK SDK for Java's dependency declarations, maven transitively includes log4j-slf4j-impl, resulting in SLF4J having two competing implementations on the classpath, only one of which is valid. This leads to the "multiple bindings" error at startup (described in the link above), and then any libraries (including ASK) which log via SLF4J do not get their log messages routed to log4j (instead they fall back to stderr).
Your Environment
ASK Java SDK version used: 2.30.0
Operating System and version: Ubuntu Linux 18.04
Java Info
Java version used for development: openjdk version "1.8.0_265"
I'm submitting a...
Libraries should not depend on an SLF4J binding, as that imposes a specific choice of logging implementation on clients of the library.
Please read this section of the SLF4J docs: http://www.slf4j.org/codes.html#multiple_bindings
Specifically note this paragraph at the end of that section:
Expected Behavior
The pom.xml files for the ASK SDK artifacts should depend on slf4j-api, and not log4j-slf4j-impl.
Current Behavior
Currently, these pom.xml files include a dependency on log4j-slf4j-impl: https://repo1.maven.org/maven2/com/amazon/alexa/ask-sdk-runtime/2.35.0/ask-sdk-runtime-2.35.0.pom https://repo1.maven.org/maven2/com/amazon/alexa/ask-sdk-model-runtime/1.0.4/ask-sdk-model-runtime-1.0.4.pom
Possible Solution
Replace log4j-slf4j-impl dependency with slf4j-api dependency, and let the clients of your library supply the implementation of SLF4J that matches their underlying logging system (log4j v1, log4j v2, Logback, etc.)
Context
We use log4j v1, and provide the log4j v1 SLF4J implementation (slf4j-log4j12) in our classpath, but because of the ASK SDK for Java's dependency declarations, maven transitively includes log4j-slf4j-impl, resulting in SLF4J having two competing implementations on the classpath, only one of which is valid. This leads to the "multiple bindings" error at startup (described in the link above), and then any libraries (including ASK) which log via SLF4J do not get their log messages routed to log4j (instead they fall back to stderr).
Your Environment
Java Info