doAs makes for nice looking code, but considering this change would break
existing code, what version would it be in?
There's also the overhead of anonymous inner classes.
On Feb 5, 2015 7:12 AM, "Aaron McCurry" <[email protected]> wrote:
> 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
> >
>
