stack commented on HBASE-15982:
RE is broke unless we stay on Guava 0.12 until the end of time. We can't stay
on Guava 0.12 because others on our CLASSPATH won't abide. The Guavas will
clash. I can't copy the 0.12 Guava classes to our codebase (we actually expose
Guavas AbstractService implementation in BaseReplicationEndpoint so there'd be
a bunch), and they'd be in a different package so implementations are broke. RE
is broke in 2.0.
Let me take advantage of the breakage to redo RE Interface. Let me try and
dredge up what folks wanted of our RE.
Meantime .001 is a proposal, a first cut. It adds minimum methods from Guava
Service; start/stop/isRunning/wait. It also takes BaseReplicationEndpoint
Private when it was LimitedPrivate in branch-1; BRE is an implementation that
extends Guava AbstractService exposing it as part of our API. Implementators
might want do implementation otherwise. They don't need AbstractService given
the limited subset of methods carried over from Service to RE. I probably need
to bring stuff from BRE back to RE.
Attempts at keeping the hierarchy where RE implemented a 'Service' that tried
to proxy to Guava Service I couldn't make work; our RE implementations use
Guava AbstractService and making the types agree failed (States, Guava's
Service vs our Service). In our RE we have isRunning, etc., but start/stop
instead of startAsync/stopAsync as it is in Guava; semantic is same but names
had to be different so could proxy calls to the backing Guava implementations.
Regards our own half-done o.a.h.h.Service, lets just remove it and use Guava
> Interface ReplicationEndpoint extends Guava's Service
> Key: HBASE-15982
> URL: https://issues.apache.org/jira/browse/HBASE-15982
> Project: HBase
> Issue Type: Bug
> Reporter: Andrew Purtell
> Priority: Blocker
> Fix For: 2.0.0
> Attachments: HBASE-15982.master.001.patch
> We have Guava's Service leaking into the LimitedPrivate interface
> public interface ReplicationEndpoint extends Service,
> This required a private patch when I updated Guava for our internal
> deployments. This is going to be a problem for us for long term maintenance
> and implenters of pluggable replication endpoints. LP is only less than
> public by a degree. We shouldn't leak types from third part code into either
> Public or LP APIs in my opinion. Let's fix.
This message was sent by Atlassian JIRA