Ooof. OK
- <artifactId>slf4j-jdk14</artifactId> is for making slf4j output/emit jdk14 logging events.
- mexp.jar is also an emitter of slf4j logging events (this is now an slf4j binding conflict)
- jetty doesn't use log4j, it uses its own StdErrLog (emit to System.err), or Slf4jLog (if slf4j is present, emit to slf4j api), and can be configured for JavaUtilLog (emit to jdk14 logging api).
- Since you have slf4j present on your classpath Jetty is likely using the Slf4jLog implementation internally.
First things first, you have to understand how slf4j works.
It has 2 basic features.
- It can masquerade and be any (1..n) of the popular logging frameworks from the point of view of those APIs
- It can route to any logging framework you want. This is called the binding layer. There can be only 1. Pick wisely.
Now, if you want to capture everything, but only use log4j for actual "to file" management, you'll want the following.
Your type 1 (masquerade) jars
- jul-to-slf4j.jar - pretends to be a java.util.logging Logger (routes to slf4j)
- jcl-over-slf4j.jar - pretends to be commons-logging (routes to slf4j)
- slf4j-api.jar - the actual log4j api jar
Your type 2 (binding) jar
- slf4j-log4j.jar - slf4j routing to log4j implementation
Your log file management jar
- log4j.jar - the logging layer you seem to want to use
Do this and you'll start to be able to configure your logging via log4j, no matter what class / library emitted the logging event.