[
https://issues.apache.org/jira/browse/HBASE-15638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239497#comment-15239497
]
Sergey Soldatov commented on HBASE-15638:
-----------------------------------------
{qoute}
So, shade in the top-level pom?
{quote}
Yep.
{quote}
How will it resolve the ByteString issue? The API being called is from HDFS...
HDFS has not been shaded. It wants com.google.pb.ByteString but we are passing
it org.apache.hbase.shaded.com.google.pb.ByteString.
{quote}
Ah. I didn't notice that {{setPayload}} method returns ByteString. Well, that
depends on whether HDFS dependency it are included in the final artifact or
not. If it is, than shaded version will be called. Otherwise you may just
exclude a single class from the relocation.
> Shade protobuf
> --------------
>
> Key: HBASE-15638
> URL: https://issues.apache.org/jira/browse/HBASE-15638
> Project: HBase
> Issue Type: Bug
> Components: Protobufs
> Reporter: stack
> Attachments: as.far.as.server.patch
>
>
> Shade protobufs so we can move to a different version without breaking the
> world. We want to get up on pb3 because it has unsafe methods that allow us
> save on copies; it also has some means of dealing with BBs so we can pass it
> offheap DBBs. We'll probably want to change PB3 to open it up some more too
> so we can stay offheap as we traverse PB. This issue comes of [~anoop.hbase]
> and [~ram_krish]'s offheaping of the readpath work.
> This change is mostly straight-forward but there are some tricky bits:
> # How to interface with HDFS? It wants its ByteStrings. Here in particular
> in FanOutOneBlockAsyncDFSOutputSaslHelper:
> {code}
> if (payload != null) {
> builder.setPayload(ByteString.copyFrom(payload));
> }
> {code}
> # [~busbey] also points out that we need to take care of endpoints done as
> pb. Test at least.
> Let me raise this one on the dev list too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
