[
https://issues.apache.org/jira/browse/HBASE-11118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033118#comment-14033118
]
Andrew Purtell commented on HBASE-11118:
----------------------------------------
I looked at protostuff a bit more. According to ohloh.net,
{quote}
In a Nutshell, protostuff...
... has had 1,090 commits made by 7 contributors representing 68,359 lines of
code
... is mostly written in Java with a low number of source code comments
... has a codebase with a long source history maintained by by one developer
with stable Y-O-Y commits
{quote}
This might be all from before the fork from Google Code to GitHub. The GitHub
project has 3 contributors.
It's nice the compiler is Java. There is an available Maven build plugin.
Extensions are not supported (but we don't use them)
We will need to support any coprocessor implementor who coded an Endpoint,
using the com.google.protobuf API. This means adding classes in a
com.google.protobuf package that forward to the real implementation. The
current patch also has this issue.
The API is quite different from protobuf-java 2.5 and missing all of the
RpcChannel and Service bits. We will need to reimplement our RPC one way or
another, probably by bringing over RpcChannel and Service from protobuf and
implementing them on top of protostuff if we want to be API compatible with
coprocessors as above and our existing codebase.
All this for a ByteString that doesn't copy...
> 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)
