Here's a ticket for the discussion:
I found what you are mentioning, and I was able to integrate my custom
coprocessor in GeoMesa by calling out to
rs.getCoprocessorHost.preScannerOpen(scan) in order to enable the
VisibilityController to insert its filters...
To be honest, this is definitely a corner case. I think the fix might
be to have the Region.getScanner implementation (2) to call out to any
other Coprocessors to intercept as they are designed to.
On 2018-04-09 06:49, Anoop John wrote:
Just taking your eg: Use cell level labels along with
AggregationClient - Tt will NOT work. The reason is the Aggregation
impl for the server side will create scanner directly over the Region.
As you know, the cell level security features work with the help of a
co processor and it expects the CP to be informed while opening of
scanner. But the CP contact while opening the scanner is one layer
above the Region level (ie at RSRpcServices). So when the
Aggregation service impl is opening the scanner, the visibility
related CP will not get into pic. If that was not the case, the
rest of the things would have been just fine for ur need. Mind
opening an issue and we discuss under that for the possible fixes?
On Fri, Mar 30, 2018 at 8:57 PM, Jim Hughes <jhug...@ccri.com> wrote:
I'm interested in combining an HBase Coprocessor with cell level
As a quick example, suppose one wanted to use the ColumnAggregation
Processor with cells with different authorizations. Different users
be able to scan and see the sum of the entries that they'd normally be
From the first few hours of looking, it appears that Coprocessors call
to the RegionServer's getScanner method which does not apply any
Have others had success combining custom coprocessors with cell-level
security? That is, are there any pointers for getting started?