[
https://issues.apache.org/jira/browse/HBASE-14944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045821#comment-15045821
]
Andrew Purtell edited comment on HBASE-14944 at 12/7/15 10:00 PM:
------------------------------------------------------------------
For SplitTransaction and RegionMergeTransaction we could add add new methods
getRequestUser and setRequestUser for accessing the request user (and setting
it), but this leaves us with the same problem, new abstract methods, because
these are both interfaces.
For the compaction related changes to Store we can carry around the request
User within CompactionContext and CompactionRequest. CompactionContext is
private. CompactionRequest is LP(Coprocessor). Both are abstract classes so by
providing implementations of getters and setters we won't cause source or
binary compat problems. We would however introduce new methods so any users of
same in code written against new release N would not compile after rollback to
N-1.
Any other ideas [~ndimiduk], [~ted_yu] ?
Also for sake of completeness, we have the option of reverting the chain of
commits leading to this point back to the original security bug fix for secure
bulk load, and advise in the troubleshooting section of the manual and/or
release notes that we can't fix the problem in 1.0 or 1.1.
was (Author: apurtell):
For SplitTransaction and RegionMergeTransaction we could add add new methods
getRequestUser and setRequestUser for accessing the request user (and setting
it), but this leaves us with the same problem, new abstract methods, because
these are both interfaces.
For the compaction related changes to Store we can carry around the request
User within CompactionContext and CompactionRequest. CompactionContext is
private. CompactionRequest is LP(Coprocessor). Both are abstract classes so by
providing implementations of getters and setters we won't cause source or
binary compat problems. We would however introduce changes where code written
against new release N won't compile after rollback to N-1.
Any other ideas [~ndimiduk], [~ted_yu] ?
Also for sake of completeness, we have the option of reverting the chain of
commits leading to this point back to the original security bug fix for secure
bulk load, and advise in the troubleshooting section of the manual and/or
release notes that we can't fix the problem in 1.0 or 1.1.
> Minimize or eliminate source incompatible changes due to HBASE-14605,
> HBASE-14631, and HBASE-14655
> --------------------------------------------------------------------------------------------------
>
> Key: HBASE-14944
> URL: https://issues.apache.org/jira/browse/HBASE-14944
> Project: HBase
> Issue Type: Sub-task
> Reporter: Andrew Purtell
> Priority: Blocker
> Fix For: 1.1.3, 1.0.4
>
>
> Minimize or eliminate source incompatible changes due to HBASE-14605,
> HBASE-14631, and HBASE-14655. The changes are due to abstract method
> additions to carry the correct (not current) {{User}} through to where
> authoritative decisions or audit is performed.
> HBASE-14605 introduces source incompatible changes to the SplitTransaction
> interface:
> - Adds abstract method execute(Server, RegionServerServices, User)
> - Adds abstract method rollback(Server, RegionServerServices, User)
> HBASE-14631 introduces source incompatible changes to the
> RegionMergeTransaction interface:
> - Adds abstract method execute(Server, RegionServerServices, User)
> - Adds abstract method rollback(Server, RegionServerServices, User)
> HBASE-14655 introduces source incompatible changes to the Store interface:
> - Adds abstract method compact(CompactionContext,
> CompactionThroughputController, User)
> - Adds abstract method requestCompaction( int, CompactionRequest, User)
> Default implementations are provided for binary compatibility but
> implementors of these interface won't recompile until implementations of the
> new methods are added.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
