[
https://issues.apache.org/jira/browse/HBASE-11118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036962#comment-14036962
]
David Yu commented on HBASE-11118:
----------------------------------
-- protostuff dev here
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).
Maintenance is easy with upstream since you're only modifying one source
(ByteString) which will not be evolving much at all.
"Thinking on it more, not generating the rpc/server bindings is a blocker. It
would be mountains of work hand coding something that is now generated hooking
up rpc invocation w/ Service call through to server/client"
If you still want to experiment with protostuff, I can help with this.
Its only a matter of having existing code, then converting that into a template.
Looking at the codebase, is it safe to assume that hbase's use of protobuf-rpc
are all blocking (not asynchronous)?
Do you use the reflection bits at all (e.g newReflectiveService)?
I see some hacks like "Ugly delegation just so we can add in a Close method.",
which I guess is caused by the inability to customize the codegen.
[~posix4e] Daniel aye?
> 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)
