hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Dimiduk (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11118) non environment variable solution for "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.LiteralByteString"
Date Fri, 11 Jul 2014 16:10:13 GMT

    [ https://issues.apache.org/jira/browse/HBASE-11118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058936#comment-14058936
] 

Nick Dimiduk commented on HBASE-11118:
--------------------------------------

[~fs111] please give it another shot. The compat.module issues are a side-effect of how the
HBase build is managed for hadoop1/hadoop2 compatibility. Basically, Stack and I were both
lazy in how we built and published jars. I've done it properly now and the build of cascading.hbase
is now working for me with the following patch applied.

{noformat}
diff --git a/build.gradle b/build.gradle
index 75f3b46..5f25ea9 100644
--- a/build.gradle
+++ b/build.gradle
@@ -60,6 +60,7 @@ allprojects {
     mavenCentral()
     maven{ url 'http://conjars.org/repo/' }
     maven{ url 'https://repository.apache.org/content/repositories/releases/' }
+    maven{ url 'http://people.apache.org/~ndimiduk/repository/' }
   }
   version = releaseVersion
 }
diff --git a/cascading-hbase-hadoop/build.gradle b/cascading-hbase-hadoop/build.gradle
index 6507a1a..d631762 100644
--- a/cascading-hbase-hadoop/build.gradle
+++ b/cascading-hbase-hadoop/build.gradle
@@ -20,7 +20,7 @@
 
 apply from: "${rootDir}/etc/hadoop-shared-config.gradle"
 
-ext.hbaseVersion = '0.98.1-hadoop1'
+ext.hbaseVersion = '0.98.4-hadoop1-SNAPSHOT'
 ext.hadoopVersion = '1.2.1'
 
 dependencies {
diff --git a/cascading-hbase-hadoop2-mr1/build.gradle b/cascading-hbase-hadoop2-mr1/build.gradle
index f36fc99..91e62ad 100644
--- a/cascading-hbase-hadoop2-mr1/build.gradle
+++ b/cascading-hbase-hadoop2-mr1/build.gradle
@@ -24,7 +24,7 @@ idea {
   pathVariables MODULE_DIR: file( "${rootDir}/cascading-hbase-hadoop" )
 }
 
-ext.hbaseVersion = '0.98.1-hadoop2'
+ext.hbaseVersion = '0.98.4-hadoop2-SNAPSHOT'
 ext.hadoopVersion = '2.2.0'
 
 dependencies {
{noformat}

> non environment variable solution for "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString
cannot access its superclass com.google.protobuf.LiteralByteString"
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-11118
>                 URL: https://issues.apache.org/jira/browse/HBASE-11118
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.98.2
>            Reporter: André Kelpe
>            Priority: Blocker
>             Fix For: 0.99.0, 0.98.4, 2.0.0
>
>         Attachments: 11118.098-0.txt, 11118.098.txt, 11118.bytestringer.txt, 1118.suggested.undoing.optimization.on.clientside.txt,
1118.suggested.undoing.optimization.on.clientside.txt, HBASE-11118-0.98.00.patch, HBASE-11118-0.98.01.patch,
HBASE-11118-0.98.02.patch, HBASE-11118-0.98.patch.gz, HBASE-11118-trunk.patch.gz, HBASE-11118.00.patch,
HBASE-11118.01.patch, HBASE-11118.02.patch, shade_attempt.patch
>
>
> I am running into the problem described in https://issues.apache.org/jira/browse/HBASE-10304,
while trying to use a newer version within cascading.hbase (https://github.com/cascading/cascading.hbase).
> One of the features of cascading.hbase is that you can use it from lingual (http://www.cascading.org/projects/lingual/),
our SQL layer for hadoop. lingual has a notion of providers, which are fat jars that we pull
down dynamically at runtime. Those jars give users the ability to talk to any system or format
from SQL. They are added to the classpath  programmatically before we submit jobs to a hadoop
cluster.
> Since lingual does not know upfront , which providers are going to be used in a given
run, the HADOOP_CLASSPATH trick proposed in the JIRA above is really clunky and breaks the
ease of use we had before. No other provider requires this right now.
> It would be great to have a programmatical way to fix this, when using fat jars.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message