[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403091#comment-16403091 ] Josh Elser commented on HBASE-20201: .001 Needs the thirdparty changes, but tested this patch and I can run a custom MapReduce job with HBase 2 against Hadoop3 (all of Hadoop 2.x would also be broken, to be clear) using {{hadoop jar}}. > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-20201.001.patch > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16401061#comment-16401061 ] Josh Elser commented on HBASE-20201: bq. Yuck on new hbase-thirdparty but yeah, if this only recourse. It looks like commons-cli has no dependencies so it should be an easy integration Yeah. It's a shame that commons-cli didn't break things more nicely, but oh well. bq. If we're going to roll a new hbase-thirdparty, we should try and figure if other stuff that needs integrating. Anything specific in mind? Or just a poll to the dev list? bq. I can roll it if you want but would be great if the knowledge got shared around... Oh, no worries. I was intending to volunteer to do that. Don't need to push that on you. I should make myself competent enough to do it. > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400772#comment-16400772 ] stack commented on HBASE-20201: --- bq. That is a #3 option, but I think a bad one. Ok. Thanks for taking a look. Yuck on new hbase-thirdparty but yeah, if this only recourse. It looks like commons-cli has no dependencies so it should be an easy integration. http://mvnrepository.com/artifact/commons-cli/commons-cli/1.4 If we're going to roll a new hbase-thirdparty, we should try and figure if other stuff that needs integrating. I can roll it if you want but would be great if the knowledge got shared around... > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400737#comment-16400737 ] Josh Elser commented on HBASE-20201: {quote}So, roll back our commons-cli? If we remove it, what breaks? We need it? {quote} That is a #3 option, but I think a bad one. Appy brought it in for some good reasons (see the RN on HBASE-17050). {quote}Best as I can tell for H2, we'd be broken in the same manner as we are for H3. I can only guess that the reason we haven't seen this previously is due to jobs that don't use the AbstractHBaseTool {quote} I did poke at this some more last night: we've missed it in our testing because we don't use {{hadoop jar}} to run our {{Tool}}s. Hadoop has been on commons-cli 1.2 for a while now, and we haven't gotten hbase2 in the hands of folks who have {{hadoop jar}} in their workflow. I think third-party inclusion is the "right" solution (just "sighing" because it's the most work). Would you be OK with me trying my hand at that, [~stack]? > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400703#comment-16400703 ] stack commented on HBASE-20201: --- So, roll back our commons-cli? If we remove it, what breaks? We need it? Thanks [~elserj] > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399176#comment-16399176 ] Josh Elser commented on HBASE-20201: Best as I can tell for H2, we'd be broken in the same manner as we are for H3. I can only guess that the reason we haven't seen this previously is due to jobs that don't use the AbstractHBaseTool (admittedly, I'm surprised we haven't seen it yet). > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399173#comment-16399173 ] Josh Elser commented on HBASE-20201: Just an FYI (not a blame) [~appy]. Looks like your change to bump commons-cli to 1.3.1 was what got the ball rolling here. > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399139#comment-16399139 ] Josh Elser commented on HBASE-20201: {quote}Can we do w/o commons-cli? If we do #1, are we broke on hadoop2 {quote} I knew someone would ask that :P. Gotta look at that still. > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399113#comment-16399113 ] stack commented on HBASE-20201: --- Can we do w/o commons-cli? If we do #1, are we broke on hadoop2? Thanks Josh. > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399099#comment-16399099 ] Josh Elser commented on HBASE-20201: {quote}Does #1 work or will it fail somewhere else down the line because underlying hadoop things end up using the wrong commons-cli? {quote} I successfully ran a test locally doing #1. Obviously, your guess is as good as mine as to whether there is something weird we'll find later. > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3
[ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399093#comment-16399093 ] Mike Drob commented on HBASE-20201: --- Does #1 work or will it fail somewhere else down the line because underlying hadoop things end up using the wrong commons-cli? > HBase must provide commons-cli-1.4 for mapreduce jobs with H3 > - > > Key: HBASE-20201 > URL: https://issues.apache.org/jira/browse/HBASE-20201 > Project: HBase > Issue Type: Bug > Components: mapreduce >Reporter: Romil Choksi >Assignee: Josh Elser >Priority: Blocker > Fix For: 2.0.0 > > > Been trying to get some pre-existing mapreduce tests working against HBase2. > There's an inherent problem right now that hadoop-common depends on > commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you > use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, > you'll get an error like: > {noformat} > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/commons/cli/DefaultParser > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) > at > org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270) > at hbase_it.App.main(App.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.apache.hadoop.util.RunJar.run(RunJar.java:239) > at org.apache.hadoop.util.RunJar.main(RunJar.java:153) > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.cli.DefaultParser > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 11 more{noformat} > My guess is that in previous versions, we didn't have this conflict with > Hadoop (we were on the same version). Now, we're not. > I see two routes: > # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the > classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} > environment variable > # We put commons-cli into our hbase-thirdparty and stop using it directly. > The former is definitely quicker, but I'm guessing the latter would insulate > us more nicely. > Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)