hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Yu (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 Thu, 19 Jun 2014 06:40:25 GMT

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

David Yu commented on HBASE-11118:
----------------------------------

First off, I'm not Daniel :-)

{quote}
The problem is classloading a protobuf ahead of our doctored one, one that is in the CLASPATH
already put there by hadoop.
{quote}
I see.  Would hadoop consider moving to your forked protobuf?  If adding ByteString.wrap is
the only modification, along with a field option (wrap = true) to make the protoc codegen
emit ByteString.wrap, I'm sure its not a problem since no incompatibility will arise (new
behavior is only activated by a new field option).

{quote}
Thank you. What happens then if we add new methods to the Interfaces? We'd have to modify
the template? 
{quote}
No modification needed.  You'll just have to use a service option/annotation that activates
the extra method generation in the template.

{quote}
(The protobuf generated classes are massive, they are half our lines of code).
{quote}
Indeed they are.  There are variants (LITE_RUNTIME, etc) when you do not need the extra stuff
(reflection, extension, descriptor, unknown fields, etc).
Ofc you can always customize the output by working with protoc-gen

{quote}
Yeah, I suppose we're being lazy and we should be going back modifying protoc generation
{quote}
Yes and yes

> 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
>
>         Attachments: 1118.suggested.undoing.optimization.on.clientside.txt, 1118.suggested.undoing.optimization.on.clientside.txt,
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)

Mime
View raw message