[
https://issues.apache.org/jira/browse/HBASE-16756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16178080#comment-16178080
]
stack commented on HBASE-16756:
-------------------------------
I just noticed this old, pertinent remark in the refguide around Coprocessor
Endpoints:
bq. Coprocessor Endpoints should make no use of HBase internals and only avail
of public APIs; ideally a CPEP should depend on Interfaces and data structures
only. This is not always possible but beware that doing so makes the Endpoint
brittle, liable to breakage as HBase internals evolve. HBase internal APIs
annotated as private or evolving do not have to respect semantic versioning
rules or general java rules on deprecation before removal. While generated
protobuf files are absent the hbase audience annotations — they are created by
the protobuf protoc tool which knows nothing of how HBase works — they should
be consided @InterfaceAudience.Private so are liable to change.
>From http://hbase.apache.org/book.html#cpeps
> InterfaceAudience annotate our protobuf; distinguish internal; publish public
> -----------------------------------------------------------------------------
>
> Key: HBASE-16756
> URL: https://issues.apache.org/jira/browse/HBASE-16756
> Project: HBase
> Issue Type: Task
> Components: Protobufs
> Reporter: stack
>
> This is a follow-on from the work done over in HBASE-15638 Shade protobuf.
> Currently protobufs are not annotated as our java classes are even though
> they are being used by downstream Coprocessor Endpoints; i.e. if a CPEP wants
> to update a Cell in HBase or refer to a server in the cluster, 9 times out of
> 10 they will depend on the HBase Cell.proto and its generated classes or the
> ServerName definition in HBase.proto file.
> This makes it so we cannot make breaking changes to the Cell type or relocate
> the ServerName definition to another file if we want CPEPs to keep working.
> The issue gets compounded by HBASE-15638 "Shade protobuf" where protos used
> internally are relocated, and given another package name altogether.
> Currently we leave behind the old protos (sort-of duplicated) so CPEPs keep
> working but going forward, IF WE CONTINUE DOWN THIS PATH OF SHADING PROTOS
> (we may revisit if hadoop ends up isolating its classpath), then we need to
> 'publish' protos that we will honor as we would classes annotate with
> @InterfaceAudience.Public as part of our public API going forward.
> What is involved is a review of the current protos under hbase-protocol. Sort
> out what is to be made public. We will likely have to break up current proto
> files into smaller collections since they currently contain mixes of public
> and private types. Deprecate the fat Admin and Client protos. This will
> allow us to better narrow the set of what we make public. These new files
> could live in the hbase-protocol module suitably annotated or they could be
> done up in a new module altogether. TODO.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
