[jira] [Commented] (HADOOP-16320) Workaround bug with commons-configuration to be able to emit Ganglia metrics to multiple sink servers
[ https://issues.apache.org/jira/browse/HADOOP-16320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844148#comment-16844148 ] Thomas Poepping commented on HADOOP-16320: -- Great, thanks Steve, I'll get to work on that. > Workaround bug with commons-configuration to be able to emit Ganglia metrics > to multiple sink servers > - > > Key: HADOOP-16320 > URL: https://issues.apache.org/jira/browse/HADOOP-16320 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 2.9.2, 2.9.3 >Reporter: Thomas Poepping >Assignee: Thomas Poepping >Priority: Minor > Attachments: HADOOP-16320.patch > > > AbstractGangliaSink is used by the hadoop-metrics2 package to emit metrics to > Ganglia. Currently, this class uses the apache commons-configuration package > to read from the hadoop-metrics2.properties file. commons-configuration is > outdated, and has a bug where the .getString function drops everything after > the first comma. This change uses .getList instead, which will work for one > or many Ganglia sink servers. > > This is fixed in trunk by upgrading to commons-configuration2, which doesn't > have the bug anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-16320) Workaround bug with commons-configuration to be able to emit Ganglia metrics to multiple sink servers
[ https://issues.apache.org/jira/browse/HADOOP-16320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Poepping updated HADOOP-16320: - Attachment: HADOOP-16320.patch > Workaround bug with commons-configuration to be able to emit Ganglia metrics > to multiple sink servers > - > > Key: HADOOP-16320 > URL: https://issues.apache.org/jira/browse/HADOOP-16320 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 2.9.2, 2.9.3 >Reporter: Thomas Poepping >Assignee: Thomas Poepping >Priority: Minor > Attachments: HADOOP-16320.patch > > > AbstractGangliaSink is used by the hadoop-metrics2 package to emit metrics to > Ganglia. Currently, this class uses the apache commons-configuration package > to read from the hadoop-metrics2.properties file. commons-configuration is > outdated, and has a bug where the .getString function drops everything after > the first comma. This change uses .getList instead, which will work for one > or many Ganglia sink servers. > > This is fixed in trunk by upgrading to commons-configuration2, which doesn't > have the bug anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-16320) Workaround bug with commons-configuration to be able to emit Ganglia metrics to multiple sink servers
[ https://issues.apache.org/jira/browse/HADOOP-16320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16842821#comment-16842821 ] Thomas Poepping commented on HADOOP-16320: -- Bug in commons-configuration was found by experiment. This is reproducible by starting more than one ganglia server and providing a comma-separated list in the configuration. > Workaround bug with commons-configuration to be able to emit Ganglia metrics > to multiple sink servers > - > > Key: HADOOP-16320 > URL: https://issues.apache.org/jira/browse/HADOOP-16320 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 2.9.2, 2.9.3 >Reporter: Thomas Poepping >Assignee: Thomas Poepping >Priority: Minor > Attachments: HADOOP-16320.patch > > > AbstractGangliaSink is used by the hadoop-metrics2 package to emit metrics to > Ganglia. Currently, this class uses the apache commons-configuration package > to read from the hadoop-metrics2.properties file. commons-configuration is > outdated, and has a bug where the .getString function drops everything after > the first comma. This change uses .getList instead, which will work for one > or many Ganglia sink servers. > > This is fixed in trunk by upgrading to commons-configuration2, which doesn't > have the bug anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-16320) Workaround bug with commons-configuration to be able to emit Ganglia metrics to multiple sink servers
[ https://issues.apache.org/jira/browse/HADOOP-16320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Poepping updated HADOOP-16320: - Status: Patch Available (was: Open) > Workaround bug with commons-configuration to be able to emit Ganglia metrics > to multiple sink servers > - > > Key: HADOOP-16320 > URL: https://issues.apache.org/jira/browse/HADOOP-16320 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 2.9.2, 2.9.3 >Reporter: Thomas Poepping >Assignee: Thomas Poepping >Priority: Minor > Attachments: HADOOP-16320.patch > > > AbstractGangliaSink is used by the hadoop-metrics2 package to emit metrics to > Ganglia. Currently, this class uses the apache commons-configuration package > to read from the hadoop-metrics2.properties file. commons-configuration is > outdated, and has a bug where the .getString function drops everything after > the first comma. This change uses .getList instead, which will work for one > or many Ganglia sink servers. > > This is fixed in trunk by upgrading to commons-configuration2, which doesn't > have the bug anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Created] (HADOOP-16320) Workaround bug with commons-configuration to be able to emit Ganglia metrics to multiple sink servers
Thomas Poepping created HADOOP-16320: Summary: Workaround bug with commons-configuration to be able to emit Ganglia metrics to multiple sink servers Key: HADOOP-16320 URL: https://issues.apache.org/jira/browse/HADOOP-16320 Project: Hadoop Common Issue Type: Bug Components: metrics Affects Versions: 2.9.2, 2.9.3 Reporter: Thomas Poepping Assignee: Thomas Poepping AbstractGangliaSink is used by the hadoop-metrics2 package to emit metrics to Ganglia. Currently, this class uses the apache commons-configuration package to read from the hadoop-metrics2.properties file. commons-configuration is outdated, and has a bug where the .getString function drops everything after the first comma. This change uses .getList instead, which will work for one or many Ganglia sink servers. This is fixed in trunk by upgrading to commons-configuration2, which doesn't have the bug anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-15525) s3a: clarify / improve support for mixed ACL buckets
[
https://issues.apache.org/jira/browse/HADOOP-15525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506657#comment-16506657
]
Thomas Poepping commented on HADOOP-15525:
--
[~fabbri] FWIW AWS IAM can do this with IAM policies.
https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/
Which is to say that a certain IAM policy attached to (probably) an IAM role
can only read/list/delete something under a specific keyspace in S3.
The solution for this in AWS EMR is to provide a mapping in configuration that
EmrFS (EMR's internal Hadoop-compatible S3 filesystem) uses to assume those
roles to get different credentials before making requests to S3.
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html
On EMR, this is a little simpler because the service controls provisioning of
the cluster. It is likely to be a more ambiguous problem to solve in open
source, where any users can deploy it anywhere.
I was responsible for the AWS EMR solution to this problem, I would be happy to
involve myself as much as I'm allowed in preparation of this feature.
> s3a: clarify / improve support for mixed ACL buckets
>
>
> Key: HADOOP-15525
> URL: https://issues.apache.org/jira/browse/HADOOP-15525
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs/s3
>Affects Versions: 3.0.0
>Reporter: Aaron Fabbri
>Assignee: Aaron Fabbri
>Priority: Major
>
> Scenario: customer wants to only give a Hadoop cluster access to a subtree of
> an S3 bucket.
> For example, assume Hadoop uses some IAM identity "hadoop", which they wish
> to grant full permission to everything under the following path:
> s3a://bucket/a/b/c/hadoop-dir
> they don't want hadoop user to be able to read/list/delete anything outside
> of the hadoop-dir "subdir"
> Problems:
> To implement the "directory structure on flat key space" emulation logic we
> use to present a Hadoop FS on top of a blob store, we need to create / delete
> / list ancestors of {{hadoop-dir}}. (to maintain the invariants (1) zero-byte
> object with key ending in '/' exists iff empty directory is there and (2)
> files cannot live beneath files, only directories.)
> I'd like us to either (1) document a workaround (example IAM ACLs) that gets
> this basic functionality, and/or (2) make improvements to make this less
> painful.
> We've discussed some of these issues before but I didn't see a dedicated JIRA.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-13276) S3a operations keep retrying if the password is wrong
[
https://issues.apache.org/jira/browse/HADOOP-13276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Poepping reassigned HADOOP-13276:
Assignee: Thomas Poepping
> S3a operations keep retrying if the password is wrong
> -
>
> Key: HADOOP-13276
> URL: https://issues.apache.org/jira/browse/HADOOP-13276
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Reporter: Steve Loughran
>Assignee: Thomas Poepping
>Priority: Minor
>
> If you do a {{hadoop fs}} command with the AWS account valid but the password
> wrong, it takes a while to timeout, because of retries happening underneath.
> Eventually it gives up, but failing fast would be better.
> # maybe: check the password length and fail if it is not the right length (is
> there a standard one? Or at least a range?)
> # consider a retry policy which fails faster on signature failures/403
> responses
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13276) S3a operations keep retrying if the password is wrong
[
https://issues.apache.org/jira/browse/HADOOP-13276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257631#comment-16257631
]
Thomas Poepping commented on HADOOP-13276:
--
Hey [~ste...@apache.org], I'll take a look into this issue. Let me know if
you've got any more information you want to share.
> S3a operations keep retrying if the password is wrong
> -
>
> Key: HADOOP-13276
> URL: https://issues.apache.org/jira/browse/HADOOP-13276
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Reporter: Steve Loughran
>Assignee: Thomas Poepping
>Priority: Minor
>
> If you do a {{hadoop fs}} command with the AWS account valid but the password
> wrong, it takes a while to timeout, because of retries happening underneath.
> Eventually it gives up, but failing fast would be better.
> # maybe: check the password length and fail if it is not the right length (is
> there a standard one? Or at least a range?)
> # consider a retry policy which fails faster on signature failures/403
> responses
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-7945) Document that Path objects do not support ":" in them.
[ https://issues.apache.org/jira/browse/HADOOP-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15889256#comment-15889256 ] Thomas Poepping commented on HADOOP-7945: - Do we have any plan to push this through? It seems like there's inconsistencies throughout the entire Hadoop ecosystem. Hadoop and HDFS should define what's allowed and what isn't. If that's following URI syntax as per the original RFC, then so be it. > Document that Path objects do not support ":" in them. > -- > > Key: HADOOP-7945 > URL: https://issues.apache.org/jira/browse/HADOOP-7945 > Project: Hadoop Common > Issue Type: Improvement >Affects Versions: 0.20.0 >Reporter: Harsh J >Priority: Critical > Labels: newbie > Attachments: HADOOP-7945.patch > > > Until HADOOP-3257 is fixed, this particular exclusion should be documented. > This is a major upsetter to many beginners. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[
https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15556662#comment-15556662
]
Thomas Poepping commented on HADOOP-13344:
--
Hey Allen, re #1:
I wrote it wrongly. The intention was for
"${HADOOP_USE_BUILTIN_SLF4J_BINDING:-true}", which will set the variable to
"true" if it is currently unset [1]
I'll look into resolving your comments for #2.
[1]
http://stackoverflow.com/questions/27445455/what-does-the-colon-dash-mean-in-bash
> 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: New Feature
> Components: bin, scripts
>Affects Versions: 2.8.0, 2.7.2
>Reporter: Thomas Poepping
>Assignee: Thomas Poepping
> Labels: patch
> Attachments: HADOOP-13344.01.patch, 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: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15491179#comment-15491179 ] Thomas Poepping commented on HADOOP-13344: -- Can someone point to what failed in the previous build? I'm not sure what went wrong. > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: Thomas Poepping > Labels: patch > Attachments: HADOOP-13344.01.patch, 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Poepping updated HADOOP-13344: - Status: Patch Available (was: Open) > 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: New Feature > Components: bin, scripts >Affects Versions: 2.7.2, 2.8.0 >Reporter: Thomas Poepping >Assignee: Thomas Poepping > Labels: patch > Attachments: HADOOP-13344.01.patch, 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490991#comment-15490991 ] Thomas Poepping commented on HADOOP-13344: -- Hm, didn't get a test run. I'll resubmit the patch? > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: Thomas Poepping > Labels: patch > Attachments: HADOOP-13344.01.patch, 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Poepping updated HADOOP-13344: - Attachment: HADOOP-13344.01.patch This patch targets trunk. Moves slf4j-related jars to a subdirectory, which will not be picked up by a wildcard. The slf4j-related jars can be optionally excluded on the classpath by setting the HADOOP_USE_BUILTIN_SLF4J_BINDING option to false. > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: Thomas Poepping > Labels: patch > Attachments: HADOOP-13344.01.patch, 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435167#comment-15435167 ] Thomas Poepping commented on HADOOP-13344: -- Terribly sorry guys, I have a different diff now that should clear a few things up. I'll get that uploaded today and we can continue the conversation from there. > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433256#comment-15433256 ] Thomas Poepping commented on HADOOP-13344: -- We cannot, because we may not have access to the other classpath. The problem here is in applications with their own classpath that consume the hadoop classpath, rather than something like a hadoop jar that wants to use its own SLF4J binding. Does that make sense? > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419433#comment-15419433 ] Thomas Poepping commented on HADOOP-13344: -- I would say we can't unconditionally remove the binding, because hadoop code itself will still need an slf4j binding to accurately log items it tries to log. I'll work to getting my updated patch posted here > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419298#comment-15419298 ] Thomas Poepping commented on HADOOP-13344: -- this seems like a different issue, but I understand what you're saying. as it stands now, it looks like hadoop-mapreduce-project, hadoop-mapreduce-client, and hadoop-minikdc all have the slf4j binding as a compile dependency, rather than a runtime dependency. changing this would exclude it for dependent projects. I would recommend a different JIRA for this issue, however, because this is not the issue I'm trying to solve here. The issue I'm trying to solve is that hadoop-config.sh will place the slf4j binding on the classpath no matter what. Applications that must be installed with hadoop to function (e.g. hive) will end up having Hadoop's slf4j-binding on their classpath, even if they don't want it there. This option would give the opportunity, in this instance, to remove that dependency from the classpath. > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419263#comment-15419263 ] Thomas Poepping commented on HADOOP-13344: -- so let's say I'm a maven based consumer of hadoop client, i.e. I have a dependency on some hadoop-client artifact in my pomfile. What would you suggest? How would I include or exclude this binding in my dependency tree? There's already a builtin way to exclude it -- using . Why go around that? > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419235#comment-15419235 ] Thomas Poepping commented on HADOOP-13344: -- Coming back to this, what downstream users would we expect? The problem we're trying to solve is that the slf4j binding is in the HADOOP_CLASSPATH variable, setup by hadoop-config.sh. That is not controllable by a downstream project, which is why I'm changing it here. If there is a downstream project including hadoop-common (or any other component), I say it's the responsibility of that project to exclude the slf4j binding if they don't want it. I don't believe any changes to pom.xml are necessary. > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15402638#comment-15402638 ] Thomas Poepping commented on HADOOP-13344: -- bump? > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[
https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385074#comment-15385074
]
Thomas Poepping commented on HADOOP-13344:
--
Sorry for the late response guys, had some other stuff come up.
I've experimented some with the patch for trunk, and it looks like I should be
able to change the directory structure in
hadoop-assemblies/src/main/resources/assemblies/hadoop-dist.xml. I've added a
new directory: slf4j-lib for each component under
/share/hadoop/${hadoop.component}/lib, and verified that the slf4j lib is not
added for common.
Does this seem like it should work to you guys? The change "for each classpath"
only affects common and the webserver modules. I wanted to run the
implementation by you guys -- it doesn't seem as complicated as you made it
sound, so I'm sure I'm missing something.
> 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: New Feature
> Components: bin, scripts
>Affects Versions: 2.8.0, 2.7.2
>Reporter: Thomas Poepping
>Assignee: 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: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373399#comment-15373399 ] Thomas Poepping commented on HADOOP-13344: -- I don't think we would want (or need to) change dependency information for anything but common, because that's the classpath most often used by other applications. I'm taking a deeper look into it. It may be that the best solution is to remove the slf4j binding from every classpath, and I agree, that would be a big change. > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371819#comment-15371819 ] Thomas Poepping commented on HADOOP-13344: -- I'm sorry Allen, I don't think I understand how that makes this a script and pom patch for any poms but the root? Wouldn't we just change the directory structure and where we put the slf4j binding, then change the script to optionally *not* add that directory to the classpath based on a variable ($HADOOP_REMOVE_SLF4J_BINDING maybe) ? Thanks for the help. > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371160#comment-15371160 ] Thomas Poepping commented on HADOOP-13344: -- I think that's a good solution for trunk. There's less messing about with grep and find and all that. I'm not sure how you guys want to proceed with branch-2. How do you think it might break compatibility? > 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: New Feature > Components: bin, scripts >Affects Versions: 2.8.0, 2.7.2 >Reporter: Thomas Poepping >Assignee: 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371117#comment-15371117 ] Thomas Poepping commented on HADOOP-13344: -- Would you suggest we keep this open, and wait until the patch is accepted to trunk before coming back to it? > 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: New Feature > 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371115#comment-15371115 ] Thomas Poepping commented on HADOOP-13344: -- The problem is not that the user slf4j binding isn't being used, it's that slf4j will report an error to stderr : "SLF4J: Class path contains multiple SLF4J bindings ... etc" https://github.com/qos-ch/slf4j/blob/c2463021fe0944a03d3fdcc14c3914c86d4a7a4f/slf4j-api/src/main/java/org/slf4j/LoggerFactory.java#L319 This change is to provide users a way around that. We default to *not* using this option (a bit of iffy not logic, I know), so that we don't unintentionally hide this error for people it might negatively affect. To your other points, understood. I'll do some looking into how we can find the offending slf4j binding in the most platform independent way. > 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: New Feature > 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[
https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15365228#comment-15365228
]
Thomas Poepping commented on HADOOP-13344:
--
That was my mistake, I didn't mean to include 2.7.2 as a target version, only
2.8.0.
I found while writing this that we could use 'jar tf ${jarname}', but that was
always much slower than grepping the jarfile directly.
As far as documentation, I don't have any plans. I assume that any
documentation that already exists regarding hadoop-config.sh should have this
feature documented. As far as client applications have documentation, I don't
see any good way to do it. We can't very well change the documentation of each
application depending on Hadoop. It could also be added to a hadoop-config help
method, if one exists. I'll look into it.
First and foremost though -- I'll be targeting trunk. The reason I targeted
this directly is because the structure of the hadoop-config file is very
different in trunk.
> 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: New Feature
> 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: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Poepping updated HADOOP-13344: - Target Version/s: 2.8.0 (was: 2.8.0, 2.7.3) > 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: New Feature > 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15365206#comment-15365206 ] Thomas Poepping commented on HADOOP-13344: -- Thanks for the quick response -- I'm working on a patch that targets trunk as well > 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Poepping updated HADOOP-13344: - Attachment: HADOOP-13344.patch > 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 >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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
[ https://issues.apache.org/jira/browse/HADOOP-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Poepping updated HADOOP-13344: - Affects Version/s: 2.8.0 Status: Patch Available (was: Open) > 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 >Affects Versions: 2.7.2, 2.8.0 >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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Created] (HADOOP-13344) Add option to exclude Hadoop's SLF4J binding
Thomas Poepping created HADOOP-13344: Summary: 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 Affects Versions: 2.7.2 Reporter: Thomas Poepping 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
