[
https://issues.apache.org/jira/browse/HBASE-15982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323048#comment-15323048
]
Enis Soztutar commented on HBASE-15982:
---------------------------------------
We've done the RE as a guava service, because our {{Service}} class is
half-finished:
{code}
// This is a WIP. We have Services throughout hbase. Either have all implement
what is here or
// just remove this as an experiment that did not work out.
// TODO: Move on to guava Service after we update our guava version; later
guava has nicer
// Service implmentation.
// TODO: Move all Services on to this one Interface.
@InterfaceAudience.Private
public interface Service {
{code}
I still want to use Guava as our long term Service interface, because the
interface it pretty well defined. However, maybe we can wrap it so that RE is
not exposed to it directly.
> 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
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.21
>
>
> We have Guava's Service leaking into the LimitedPrivate interface
> ReplicationEndpoint:
> {code}
> public interface ReplicationEndpoint extends Service,
> ReplicationPeerConfigListener
> {code}
> 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
(v6.3.4#6332)
