[
https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16013626#comment-16013626
]
Duo Zhang commented on HBASE-16757:
-----------------------------------
It would be great if they can be done at the same time. But for things like
AccessController, the function of CP is much more complicated than EP, so I
think we can do the EP change first if we do not have enough time to do the CP
change.
> 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.15#6346)
