I am writing a Java app that will use SLF4J to handle logging with a runtime binding of JUL (Java Utils Logging). Thus my classpath will have slf4j-api-1.6.4.jar as well as slf4j-jdk14-1.6.4.jar on it.
JUL can be configured via logging.properties so I will need that on my classpath too.
In order to make sure that all my 3rd party dependencies log to the same JUL configuration, I am planning on putting all of the following bridges on my classpath as well:
jcl-over-slf4j-1.6.4.jarlog4j-over-slf4j-1.6.4.jarJCL is configured via commons-logging.properties and Log4J is configured via log4j.properties.
My question: do I need to put commons-logging.properties and log4j.properties on my classpath, or is this unnecessary because of the SLF4J bridges?
I'm 90% sure I don't have to, but need a sanity check here! My theory is that the bridges replace the normal JCL/Log4J classes with stubs that just blindly call SLF4J API calls.
These SLF4J API calls in turn, like my code will do, use whatever implementations they bind to at runtime. Since the binding in my case is JUL, only a logging.properties file should be required.
But I'm not a logging expert, and I'd rather be safe than sorry. So do I need these extra config files, and if so, please explain why so I can better understand how SLF4J works! Thanks in advance!
No, you don't need to put commons-logging.properties and log4j.properties on your classpath, this unnecessary because of the SLF4J bridges. Your understanding of the brides is correct.
If you use Maven you'll likely want to use the Banned Dependencies enforcer rule to avoid dependencies to log4j, commons-logging or logback creeping in.