[
https://issues.apache.org/jira/browse/HBASE-11118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036979#comment-14036979
]
stack commented on HBASE-11118:
-------------------------------
[~d4niel] Thank you for taking the time to stop by.
bq. Reading from your comments, I think the most logical choice is to fork
protobuf and override the ByteString behavior to wrap instead of copy (either
modify ByteString.copyFrom or modify the protoc-codegen to emit
ByteString.wrap).
The problem is classloading a protobuf ahead of our doctored one, one that is
in the CLASPATH already put there by hadoop.
bq. Its only a matter of having existing code, then converting that into a
template.
Thank you. What happens then if we add new methods to the Interfaces? We'd
have to modify the template? (The protobuf generated classes are massive, they
are half our lines of code).
bq. Looking at the codebase, is it safe to assume that hbase's use of
protobuf-rpc are all blocking...
You are correct.
We want to move to async but its a bit of work that we've put off for the
moment.
bq. .... which I guess is caused by the inability to customize the codegen.
Yeah, I suppose we're being lazy and we should be going back modifying protoc
generation (that is one of the attractive things about protostuff... that we
could add it into our inline build along w/ any mods we'd want to package).
Again, thanks for coming by Daniel.
> 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)
