We could also support the "doAs" method call similar to Hadoop's API. So
something like:
// Class member variable
private Iface client = BlurClient.getClient();
// Inside a method.
...
User user = new User("user1", null);
List<String> tableList =
user.doAs(new PrivilegedExceptionAction<List<String>>() {
public List<String> run() {
return client.tableList();
}
};
Instead of:
User user = new User("user1", null);
List<String> tableList;
try {
UserContext.setUser(user);
tableList = client.tableList();
} finally {
UserContext.reset();
}
Thoughts?
Aaron
On Wed, Feb 4, 2015 at 7:45 PM, Tim Williams <[email protected]> wrote:
> I've been giving the new record filtering stuff a spin today and I've
> found bits of it non-obvious. Mainly with having both o.a.b.user.User
> and o.a.b.thrift.generated.User and setUser and UserContext.setUser.
> It turns out the UserContext gives the behavior I expected
> (implementing a BlurFilterServer) but it's not clear why we need the
> seemingly duplicitous classes/services around? From a user's
> perspective, btw, the static setter approach feels uncomfortable. I
> know, "uncomfortable" isn't very constructive - I'm hoping to offer
> that when my question is answered:)
>
> Thanks,
> --tim
>
