Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use slf4j-api instead of depending on a concrete logging provider #243

Closed
bestbeforetoday opened this issue Apr 16, 2024 · 3 comments
Closed

Use slf4j-api instead of depending on a concrete logging provider #243

bestbeforetoday opened this issue Apr 16, 2024 · 3 comments

Comments

@bestbeforetoday
Copy link
Contributor

SLF4J is designed as a facade (or abstraction) for various logging concrete logging implementations (see SLF4J documentation for details). The SLF4J has this guidance for libraries:

Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding/provider but only depend on slf4j-api.
When a library declares a transitive dependency on a specific binding, that binding is imposed on the end-user negating the purpose of SLF4J. Note that declaring a non-transitive dependency on a binding, for example for testing, does not affect the end-user.

Rather than depending on slf4j-api and allowing consumers to link to a concrete logging provider of their choice at deployment time, this project has an implementation dependency on slf4j-jdk14. I propose depending only on slf4j-api and documenting that consumers should add a dependency on their concrete logging provider of choice.
@bestbeforetoday
Copy link
Contributor Author

I am happy to work on this if you agree with the approach.

@vbarua
Copy link
Member

vbarua commented Apr 16, 2024

This seems perfectly reasonable to me. I'd be happy to review this change if you were to make it.

This was referenced Apr 17, 2024
Merged
Closed
vbarua pushed a commit that referenced this issue May 1, 2024
@bestbeforetoday
feat: allow deployment time selection of logging framework #243 (#244)
72bab63 
Depend on slf4j-api instead of the slf4j-jdk14 logging framework. This allows
consumers to select their preferred logging framework at deployment time by
adding an appropriate SLF4J provider to their runtime classpath.

If no SLF4J provider is available at runtime, no logging output will be
produced. The code still functions as expected.

The isthmus CLI command continues to log using java.util.logging by including
the slf4j-jdk14 provider in its runtime classpath.

Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
@bestbeforetoday
Copy link
Contributor Author

Resolved by PR #244 and published in v0.31.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@vbarua @bestbeforetoday