SLF4J: Bridge vs Migrator JARs
java, java.util.logging, log4j, logging, slf4j
Solution
First of all, these jars are intended for situations where your project has dependencies out of your control, and these dependencies make use of `JUL` (java.util.logging), `JCL` (Jakarta Commons Logging) or `log4j` and you would like to route all logging operations through the `slf4j-api`. Think of it as dynamically replacing all calls to those legacy logging apis with `slf4j-api` equivalents.
Each one of these 3 jars does the same thing for its respective legacy logging framework. The difference in naming (over vs to) stems from the way this translation is accomplished.
With the above in mind here are the answers to your questions:
If the code is under your control, you might as well replace all `JCL` calls with proper `slf4j-api` calls (same goes for any other legacy framework). If the source code is out of your control or you can't be bothered to replace them, you can include `jcl-over-slf4j-1.7.5.jar` in your classpath and exclude `commons-logging.jar`. That's because `jcl-over-slf4j-1.7.5.jar` contains the same classes (or a subset thereof) of `commons-logging.jar` rewritten to send all logging activity to `slf4j-api`. Hence the over name.
`jul-to-slf4j-1.7.5.jar` works its magic in a slightly different way - hence the to name. `JUL` makes use of handlers. A handler is any class that extends `java.util.logging.Handler` and is meant to handle (guess what) logging messages (or records in JUL terminology). So in this case, in order to route all `JUL` logging to `slf4j-api` we just need to make sure we register only one such handler - the `SLF4JBridgeHandler` (which happens to be the only class contained in `jul-to-slf4j-1.7.5.jar`). The configuration options to do that can be found here.
The difference between over and to should now be evident. The over jars work by replacing the very same classes of the original jars with ones that route all logging to `slf4j-api`. The `JUL` to jar doesn't need to do the same kind of class rewriting due to the way `JUL` operates with handlers (and you only need configure one handler that will route all logging to `slf4j-api`).
For more legacy notes check the excellent slf4j legacy documentation, and also be sure to check the big picture (also linked to from the main legacy article).
Hope this helps.
Problem
SLF4J (1.7.5, but really any modern version) ships with several "over" (migrator) JARs: - `jcl-over-slf4j-1.7.5.jar` - `log4j-over-slf4j-1.7.5.jar` ...as well as a "to" (bridge) JAR: - `jul-to-slf4j-1.7.5.jar` According to their docs, a migrator: ...ease[s] migration to SLF4J from [JCL/log4j]. This jar file is intended as a drop-in replacement for [JCL/log4j]. It implements the[ir] public API but using SLF4J underneath, hence the name "over" SLF4J. Whereas, the JUL bridge: routes all incoming jul records to the SLF4j API. - Do I use `jcl-over-slf4j-1.7.5.jar` when I have code that logs using JCL, but I want it to use SLF4J? Or something else? - When would I use `jul-to-slf4j-1.7.5.jar`? How is the word "to" here used differently than "over"? - Why is there no "over" JAR for JUL? Why are there no "to" JARs for JCL and log4j?