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.

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

SLF4J Failed to load #64

Open
CyberCrest opened this issue Apr 21, 2022 · 3 comments
Open

SLF4J Failed to load #64

CyberCrest opened this issue Apr 21, 2022 · 3 comments

Comments

@CyberCrest
Copy link

Your software looks fantastic. We will be using it for managing our existing sales leads database and verifying uniqueness of future entries.
The program worked with the sample data but generated a warning regarding the logger. Is there a fix for this? I plan to utilize this application a lot. Thank you for your efforts!

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Data: {[{'Steven Wilson'}, {'45th Avenue 5th st.'}]} Matched With: {[{'Stephen Wilkson'}, {'45th Ave 5th Street'}]} Score: 1.0000000000000002
Data: {[{'Stephen Wilkson'}, {'45th Ave 5th Street'}]} Matched With: {[{'Steven Wilson'}, {'45th Avenue 5th st.'}]} Score: 1.0000000000000002

@manishobhatia
Copy link
Contributor

Thanks for taking interest in this project, and appreciate bringing the SLF4J issue to our notice.
Will evaluate a fix for this, and include it in one of our next releases.

@unkish
Copy link

unkish commented Sep 23, 2023

Unfortunately it seems that adding slf4j-simple was a hasted decision.
As per https://www.slf4j.org/manual.html

Note that SLF4J-enabling your library/application implies the addition of only a single mandatory dependency, namely slf4j-api-2.0.9.jar.

What given library also did.

Warning that @CyberCrest experienced was due to missing dependency on their side (library consumer) and should have been fixed by linking with/declaring dependency on desired provider.
After 37bb328 all other users that have provider other than slf4j-simple have now to explicitly exclude it otherwise application will fail to start due to class path containing multiple SLF4J bindings

[BASIC RULE] 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.

Note also that slf4j-simple binding/provider outputs all events to System.err. Only messages of level INFO and higher are printed.

@manishobhatia
Copy link
Contributor

Reopening to evaluate this again

@manishobhatia manishobhatia reopened this Sep 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants