Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Tue, 6 May 2014 16:10:18 +0000 (UTC)
From: =?utf-8?Q?Andr=C3=A9_Kelpe_=28JIRA=29?= <jira@apache.org>
To: dev@hbase.apache.org
Message-ID: <JIRA.12712613.1399392555581.236917.1399392618441@arcas>
In-Reply-To: <JIRA.12712613.1399392555581@arcas>
References: <JIRA.12712613.1399392555581@arcas>
Subject: [jira] [Created] (HBASE-11118) non environment variable solution
 for "IllegalAccessError: class
 com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass
 com.google.protobuf.LiteralByteString"
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Andr=C3=A9 Kelpe created HBASE-11118:
-----------------------------------

             Summary: non environment variable solution for "IllegalAccessE=
rror: 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=C3=A9 Kelpe


I am running into the problem described in https://issues.apache.org/jira/b=
rowse/HBASE-10304, while trying to use a newer version within cascading.hba=
se (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. lin=
gual has a notion of providers, which are fat jars that we pull down dynami=
cally at runtime. Those jars give users the ability to talk to any system o=
r 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 re=
ally clunky and breaks the ease of use we had before. No other provider req=
uires 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)