f444b3b542
Reason for refactor: In cases where one might need to use multiple observers, say region, master and regionserver; and the fact that only one class can be extended, it gives rise to following pattern: public class BaseMasterAndRegionObserver extends BaseRegionObserver implements MasterObserver class AccessController extends BaseMasterAndRegionObserver implements RegionServerObserver were BaseMasterAndRegionObserver is full copy of BaseMasterObserver. There is an example of simple case too where the current design fails. Say only one observer is needed by the coprocessor, but the design doesn't permit extending even that single observer (see RSGroupAdminEndpoint), that leads to copy of full Bas e...Observer class into coprocessor class leading to 1000s of lines of code and this ugly mix of 5 main functions with 100 useless functions. Javadocs changes: - Adds class comments on 'default' methods and expectations. - Adds explanaiton of Exception handling in Observers' class comment. Removes redundant @throws before each function. - Improves javadocs for a bunch of functions - deletes empty @params in a bunch of places Change-Id: I265738d47e8554e7b4678e88bb916a0cc7d00ab3 |
||
|---|---|---|
| .. | ||
| src | ||
| README.txt | ||
| pom.xml | ||
README.txt
ON PROTOBUFS
This maven module has protobuf definition files ('.protos') used by hbase
Coprocessor Endpoints that ship with hbase core including tests. Coprocessor
Endpoints are meant to be standalone, independent code not reliant on hbase
internals. They define their Service using protobuf. The protobuf version
they use can be distinct from that used by HBase internally since HBase started
shading its protobuf references. Endpoints have no access to the shaded protobuf
hbase uses. They do have access to the content of hbase-protocol but avoid using
as much of this as you can as it is liable to change.
Generation of java files from protobuf .proto files included here is done apart
from the build. Run the generation whenever you make changes to the .orotos files
and then check in the produced java (The reasoning is that change is infrequent
so why pay the price of generating files anew on each build.
To generate java files from protos run:
$ mvn compile -Dcompile-protobuf
or
$ mvn compile -Pcompile-protobuf
After you've done the above, check it and then check in changes (or post a patch
on a JIRA with your definition file changes and the generated files). Be careful
to notice new files and files removed and do appropriate git rm/adds.