[jira] [Comment Edited] (HBASE-11118) non environment variable solution for "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.LiteralByteString"

["Andrew Purtell (JIRA)" <ji...@apache.org>]

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

Andrew Purtell edited comment on HBASE-11118 at 5/23/14 9:30 PM:
-----------------------------------------------------------------

bq. If we bring in protobuf, how big is that?

I rebased on latest trunk. The HBase patch is 293 files changed, 72401 insertions, 24126 deletions. I left out the protobuf tests and only brought over what is in protobuf-2.5.0/java/src/main/java, including also the generated DescriptorProtos.java from generated-sources/. That produces 45 new files in hbase-protocol. There are 31 additional test files in protobuf-2.5.0/java/src/test/. Simple enough to bring them over into hbase-protocol also with substitution.

If going this route, we would also need to update the compile-protobuf Maven magic to run a substitution over the generated result with sed. I didn't want to spend quality time with Maven if it wasn't necessary.

Edit: Fix formatting


was (Author: apurtell):
bq. If we bring in protobuf, how big is that?

I rebased on latest trunk. The HBase patch is 293 files changed, 72401 insertions(+), 24126 deletions(-). I left out the protobuf tests and only brought over what is in protobuf-2.5.0/java/src/main/java, including also the generated DescriptorProtos.java from generated-sources/. That produces 45 new files in hbase-protocol. There are 31 additional test files in protobuf-2.5.0/java/src/test/. Simple enough to bring them over into hbase-protocol also with substitution.

If going this route, we would also need to update the compile-protobuf Maven magic to run a substitution over the generated result with sed. I didn't want to spend quality time with Maven if it wasn't necessary.

> 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
>
>         Attachments: HBASE-11118-0.98.patch.gz, HBASE-11118-trunk.patch.gz, 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)