[
https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365208#comment-15365208
]
Sean Busbey commented on HADOOP-13344:
--------------------------------------
-1 (non-binding) on this going into 2.7.z. Maintenance releases aren't the
place to change the dependency set, even if it's opt-in. It invites folks to
rely on behavior that they won't be able to use if they have to revert to an
earlier maintenance release.
How are we planning to document this as an option for the client classpath?
Will operators have to have looked at the source of our scripts to know that
this feature exists?
{code}
+ find $parent_directory -maxdepth 1 -name "*.jar" -exec grep -HLs \
+ "org/slf4j/impl/StaticLoggerBinder.class" {} \; \
+ | paste -sd ':' -
{code}
At this point in bootstrapping, do we have access to a JRE that we could use to
enumerate jar contents (or some zip accessor)? that'd be more reliable than
greping the jar file directly.
> Add option to exclude Hadoop's SLF4J binding
> --------------------------------------------
>
> Key: HADOOP-13344
> URL: https://issues.apache.org/jira/browse/HADOOP-13344
> Project: Hadoop Common
> Issue Type: Improvement
> Components: bin, scripts
> Affects Versions: 2.8.0, 2.7.2
> Reporter: Thomas Poepping
> Labels: patch
> Attachments: HADOOP-13344.patch
>
>
> If another application that uses the Hadoop classpath brings in its own SLF4J
> binding for logging, and that jar is not the exact same as the one brought in
> by Hadoop, then there will be a conflict between logging jars between the two
> classpaths. This patch introduces an optional setting to remove Hadoop's
> SLF4J binding from the classpath, to get rid of this problem.
> This patch should be applied to 2.8.0, as bin/ and hadoop-config.sh structure
> has been changed in 3.0.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
