[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15547674#comment-15547674 ]
Jerry He commented on HBASE-16757: ---------------------------------- Hi, [~stack] Do you have a list? bq. The TokenProvider methods could easily be moved. I was thinking about doing this long ago. TokenProvider is easily confusing from my experience and hard to explain to people why it needs to be additionally configured. > Integrate functionality currently done up as Coprocessor Endpoints into core. > ----------------------------------------------------------------------------- > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors > Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)