[
https://issues.apache.org/jira/browse/HBASE-11118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13991026#comment-13991026
]
André Kelpe commented on HBASE-11118:
-------------------------------------
For the provider mechanism:
Lingual is a cascading app that submits itself to the cluster. You can use a
provider to talk to different data formats/sources. You basically tell lingual
in the table definition "this table is actually in Hbase, use this jar file
over there to talk to it". lingual itself does not really know about Hbase or
any other format/system, but HDFS and delimited files. We create fat jars for
those providers to keep the dependency fetching "sane". Only lingual uses those
jars. We could def. make them shaded jars, but that will not work in this case,
since protobuf is the mechanism to talk to the HBase cluster.
Next to that, my understanding of the problem at hand is that it also breaks
the classic hadoop jars with lib folders. For those we do not have any control,
since our users are just going to use cascading.hbase, build a jar and submit
it to the cluster.
> 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
> Fix For: 0.98.3
>
>
> 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)
