Minor Description
Running the oozie CLI causes the following SLF4J warning to be shown (note this is on a brand new build - freshly extracted distro tarball):
[root@183bd1d9e976 oozie-4.2.0]# ./bin/oozie admin -status --oozie http://localhost:11000/oozie
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/root/oozie-4.2.0/lib/slf4j-log4j12-1.6.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/root/oozie-4.2.0/lib/slf4j-simple-1.6.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
I'm pretty sure this was introduced in OOZIE-1876 as the client now extracts all jars in the war file to the lib/ directory, causing there to be two bindings:
[root@183bd1d9e976 oozie-4.2.0]# ls lib | grep slf4j
slf4j-api-1.6.6.jar
slf4j-log4j12-1.6.6.jar
slf4j-simple-1.6.6.jar
I think the true issue is pointing to the larger problem that client/server jars live in the same place. I think there are multiple ways to go about this:
1. Refactor in a way that further decouples the client and server, and truly decouples the two allowing them to be (and assuming they will be) installed completely separately, while still allowing them to work together. Why does Oozie client know about the war file? It shouldn't.
2. More of a halfway-fix (similar to something that was used in BIGTOP-791 to what I assume was overcome this problem) is to alter the build, and wrapper shell scripts to build their classpath from a client or server libraries folder (was libserver in the mentioned bigtop example). I'd argue keeping client libs in a "libclient" folder would be cleaner and make more sense. The server should already get all the jars it needs from the war file, right?