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
ON PROTOBUFS
This maven module has core protobuf definition files ('.protos') used by hbase
table gropuing Coprocessor Endpoints.
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.