hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15982) Interface ReplicationEndpoint extends Guava's Service
Date Mon, 15 Aug 2016 06:31:20 GMT

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

Andrew Purtell commented on HBASE-15982:

bq. 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.

It might be difficult indeed to use Guava as the basis for our Service interface if it embeds
a requirement for a Category X dependency.

We harmonize on Guava 14 for internal builds after finding something that works across HDFS,
HBase, Hive, Spark, and others. It's easy to revert the jsr305-findbugs ban on an internal
build but that won't be a workable solution upstream. 

> 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.4.0, 0.98.22
> 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

View raw message