[
https://issues.apache.org/jira/browse/HBASE-11118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14031053#comment-14031053
]
stack commented on HBASE-11118:
-------------------------------
[~tlipcon]
bq. Have we already considered using our own classloader to isolate our
dependency?
There is a bit of messy research done at the head of HBASE-10304. IIRC, we
don't get chance to do interception. RunJar is running the show. That is the
case here too [~fs111]? Are you using hadoop runjar or a similar mechanism?
bq. Instead, could we put some more pressure on the upstream protobuf
maintainers to include the ZeroCopyLiteralByteString, or at least make its
super-class non-final in order to support this?
https://code.google.com/p/protobuf/issues/detail?id=374 asks and gets shutdown
because it would break base precept that all is immutable in pb.
bq. Alternatively, could we get shading to work by adding an extra indirection
package that builds a "jar-with-dependencies" of both hbase-protocol and
protobuf, and then shades that and re-publishes as an
"hbase-protocol-with-shaded-pb" pom? Then the rest of HBase could depend on
that?
Let me try it Todd.
> 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
> Assignee: Andrew Purtell
> 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)
