Uploaded image for project: 'Oozie'
  1. Oozie
  2. OOZIE-2399

Oozie client class path contains multiple SLF4J bindings

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 4.2.0
    • Fix Version/s: None
    • Component/s: client, scripts
    • Labels:
      None

      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?

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              grimesmi Mike Grimes
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: