I have a .jar file (foo.jar, for instance) that we can't alter that contains a commons-logging.properties file (that redirects to JDK14Logging) and relies on an external commons-logging.jar file for it's logging. This, I believe is set to simply output to stdout which isn't very helpful.
We have a different logging system (log4J if it matters) that we are using, and would prefer to use. Is it possible to have an external properties file (sitting local to the foo.jar) that 'overrides' the one inside foo.jar?
I'm aware that SLF4J should work, as should editing the .jar in 7zip and 'recompiling' so to speak, but I feel that the first creates an extra dependency on a Jar (as requires bringing one into the environment) and the latter creates a dependency on someone to make the same edits we made to foo.jar to foo2.jar when/if we are provided with that when/if I have left the project.
Is this possible without editing the jar or SLF4J?? Or do I need to bite one of the aforementioned bullets?
The quick fix (assuming the default classloaders are being used) would be to create your own commons-logging.properties file, contained in a directory that is on the classpath before the jar containing the unwanted commons-logging.properties file. Your commons-logging.properties file should be configured to use Log4J and in particular your log4j.properties file.
However I'd really recommend switching to SLF4J and using the SLF4J bridge implementation of commons-logging, which will make the commons-logging API being used by the libraries on which you depend irrelevant and allow you to control the log configuration from your project (via a single logback.xml file assuming you're using Logback).