Allow Observers to completely override base function

Review Request #1295 — Created Dec. 14, 2010 and submitted

jgray, mlai
Currently an observer can act as a filter or translator but cannot stop a subsequent call down to the base method for get, put, delete, etc. This patch allows observers to 1) keep any subsequently chained observer from executing, or 2) prevent default behavior from executing. This latter option allows a preXXX hook to completely reimplement something.

I also found and fixed some logic bugs in coprocessor framework integration in HRegion.

I will squelch the added extraneous whitespace upon commit.
All coprocessor unit tests pass. No failures of other unit tests observed that might be related to these changes.
  2. presumably a co-processor could modify the Get object to implement policy?  Another consideration is replacing the Get query with an alternate query, for example we have InternalGet subclasses for additional functionality, I'm just winging this though.
  3. unless you need CAS semantics, you can just use volatile here.  We are over-using the Atomic* stuff sometimes.
  1. Looks great.  Thanks Andy!
  2. We had discussed these returning the return type but we'll pass in an empty result instead?
  3. so here we have to because it's a primitive.  so is there a reason not to do this elsewhere on the pre methods?
    Or, this is for chaining, that's why... got it
  4. there shouldn't be @return javadoc now, right?
    I think it would be noting in the javadoc that you can modify the result that is passed in though.
  5. if i don't do bypass/complete, and i play with this Result, what is the impact?  do we just drop this if the flags don't get set?
  6. looks like we drop the result.  makes sense.  not sure if we should add something to some doc somewhere but it's clear to me now.
  2. No need to return something. We are assuming the 'result' object is sufficiently modifiable by its methods. An empty result is passed in to be populated. 
  3. We assume the Get is fully modifiable via its methods. Replacing the query with something else is not a problem: The coprocessor can do just about anything from the preXXX hooks, populate the Result object with data, then tell the framework to return without invoking the base function.
  4. Yes, if you play with the result but don't call e.bypass() then there is no impact. To change the result of an increment you need to use postIncrement.
  5. I'll add a note to the javadoc.