[
https://issues.apache.org/jira/browse/HBASE-20656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16492790#comment-16492790
]
Balazs Meszaros commented on HBASE-20656:
-----------------------------------------
The package of WALEdit for example was changed in 2.0, so if we want to check
these kind of incompatibilities, we have to create an 1.x coprocessor somehow:
- write a coprocessor which depends on our 1.x source tree. It would be
possible if we created a new module in our source, but it would introduce other
building issues.
- generate programatically the class file, which requires a byte code
manipulation library,
- add it as binary into our source tree (that's what I did),
- do not check the tool at all :)
I do not know if we have any other choices.
> Validate pre-2.0 coprocessors against HBase 2.0+
> ------------------------------------------------
>
> Key: HBASE-20656
> URL: https://issues.apache.org/jira/browse/HBASE-20656
> Project: HBase
> Issue Type: New Feature
> Components: tooling
> Affects Versions: 3.0.0
> Reporter: Balazs Meszaros
> Assignee: Balazs Meszaros
> Priority: Major
> Attachments: HBASE-20656.master.001.patch
>
>
> We have co-processors for a while, but the API has been changed recently. We
> should give some tooling for our users to determine if they can use the
> previous co-processors safely or not.
> The tool should:
> - try to load the co-processors on our current classpath for ensuring class
> references are on our classpath,
> - should check for previously removed co-processor methods.
> In this version we check only method signatures. Code references should be
> checked in further versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
