The doAs solution would in addition to what is already in place. It would break any current functionally, if we decide to implement it.
On Thu, Feb 5, 2015 at 9:06 AM, Andrew <[email protected]> wrote: > 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 > > > > > >
