Skip to content
New issue

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

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

Already on GitHub? # to your account

Warning "No SLF4J providers were found" #153

Closed
vargenau opened this issue Jan 17, 2024 · 10 comments · Fixed by #158
Closed

Warning "No SLF4J providers were found" #153

vargenau opened this issue Jan 17, 2024 · 10 comments · Fixed by #158

Comments

@vargenau
Copy link
Contributor

How to get rid of the following warning:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.

tools-java release 1.1.8

@goneall
Copy link
Member

goneall commented Jan 18, 2024

I wish I knew - @pmonks do you have any ideas? Perhaps something we should configure in the main part of the app?

note related #43

@goneall
Copy link
Member

goneall commented Jan 18, 2024

@Gr33ndev - since you've helped out with the java library logging, pinging you to see if you have any solutions

@pmonks
Copy link

pmonks commented Jan 20, 2024

@vargenau this probably means you don't have an SLF4J implementation JAR in your classpath. The reason Spdx-Java-Library doesn't provide one is that there are several choices that are suited for different scenarios/preferences, and it's inappropriate for a library to make that implementation decision on behalf of all downstream consumers.

The solution is to pick one of the SLF4J implementations and add it to your classpath (perhaps via a build file, if you're using a build tool e.g. pom.xml if you're using Maven).

@vargenau
Copy link
Contributor Author

@pmonks
Thank you for your explanations.

Previously my shell-script was:

#!/bin/csh -f
java -jar /Users/mvargena/bin/tools-java/tools-java-1.1.8-jar-with-dependencies.jar Verify $*

I have updated it to:

#!/bin/csh -f
java -classpath "/Users/mvargena/Java/slf4j-api-2.0.11.jar:/Users/mvargena/Java/slf4j-nop-2.0.11.jar" -jar /Users/mvargena/bin/tools-java/tools-java-1.1.8-jar-with-dependencies.jar Verify $*

but I still get the same warnings.

What am I doing wrong?

@pmonks
Copy link

pmonks commented Jan 23, 2024

@vargenau do all those files exist in those locations? Also, IIRC tools-java has more dependencies than that, so you'll likely hit further class loading issues until you have the entire transitive dependency graph expressed on the command line.

I'd encourage you to consider using a Maven-based build tool (Maven, Gradle, etc.) instead of trying to manually manage Java dependencies like this - the approach you're taking is quite brittle and error prone.

[edit] and it looks like you're using the "with dependencies" variant of the tools-java JAR, so my advice above isn't relevant - you should simply be able to java -jar that JAR and it should work (unless there's a bug in the build that means that an SLF4J implementation isn't bundled into that JAR - @goneall do you know if that's the case?).

@vargenau
Copy link
Contributor Author

Hi @pmonks
Yes, these files exist and are readable.

I even removed the Apple quarantine flag (it's a Mac):

xattr -d com.apple.quarantine *.jar

But that does not help.

Anyway, I can live with these warnings.

@le-jhe
Copy link

le-jhe commented Mar 18, 2024

I have a proposed fix in the pull request above. Can you review it ?

@vargenau
Copy link
Contributor Author

@goneall
Hi Gary,
Could you please check if this fixes the issue?
Thank you

@goneall
Copy link
Member

goneall commented Mar 18, 2024

thanks @le-jhe for the analysis and fix.

Although the intent of this .jar file is to be used as a standalone app and not a library, I am a bit worried that it may well be used as a library and cause issues for downstream users. That being said, perhaps we should go ahead and merge this since I think most usage is as a standalone Jar.

@pmonks - any thoughts on whether we should merge in PR #158 ?

@pmonks
Copy link

pmonks commented Mar 19, 2024

@pmonks - any thoughts on whether we should merge in PR #158 ?

@goneall added a comment in the PR. I have a vague recollection that it might be possible to achieve both goals (dependency included in uberjar, but completely missing in library jar & pom) via some Maven magic.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
4 participants