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

Jonathan Hsieh commented on HBASE-11118:
----------------------------------------

Has using an alternative protobuf java lib like protostuff been considered?  
With that we could likely have more influence and get performance-oriented 
changes int and eventually percolate it to other ecosystem projects.

> 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)

Reply via email to