[
https://issues.apache.org/jira/browse/HBASE-15982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112328#comment-16112328
]
stack commented on HBASE-15982:
-------------------------------
bq. However, maybe we can wrap it so that RE is not exposed to it directly.
It doesn't look like we can 'wrap it' because Guava Service methods return
Guava State enums and Guava Service; can't intercept and return our 'State'
enum instead in an Interface; ditto Service.
Copy/paste Guava Service 0.12 into RE and undoing the extend Service is awkward
because the old Guava Service depends on other Guava classes throwing
Exceptions that are from Guava util/concurrent and returning Guava
ListenableFuture.
So, it looks like 2.0.0 has to break RE if we are to undo Guava types from its
API (in fact its already 'broke' since our move to relocated hbase-thirdparty
guava).
Regards our internal half-done Service, it is a poor shadow of Guava Service,
even of Service 0.12, nvm the current 0.22. 0.22 is nicely contained though
compared to 0.12 with its dependence on other classes.
Internally for 'Services', we could use our relocated 0.22 guava Service. Would
be fine presuming all implementations @private/internal.
RE is LimitedPrivate. It needs some form of 'Service' that can be used
semi-publicly. The 0.22 Guava Service is nice but the Listener support is OTT
for our needs. Let me just copy/paste it as our internal Service.
> 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
>
>
> 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.4.14#64029)
