[
https://issues.apache.org/jira/browse/OOZIE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Grimes updated OOZIE-2399:
-------------------------------
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?
was:
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
> Oozie client class path contains multiple SLF4J bindings
> --------------------------------------------------------
>
> Key: OOZIE-2399
> URL: https://issues.apache.org/jira/browse/OOZIE-2399
> Project: Oozie
> Issue Type: Bug
> Components: client, scripts
> Affects Versions: 4.2.0
> Reporter: Mike Grimes
> Priority: Minor
> Fix For: trunk
>
>
> 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?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
