DeadboltHandler.getSubject should be async to support non-blocking service, like it was in previous version

[Denis Borisenko]

If I use non-blocking async service to get current subject (which returns Future), I need to block it to satisfy the new version (v2.3.3) of the API. Previous version (v2.3.2) was non-blocking. Now I have to block my code like this:

trait UserService {
  def getUser[A](implicit request: Request[A]): Future[Option[User]] = ... // some non-blocking code here
}
class MyDeadboltHandler extends DeadboltHandler {
  override def getSubject[A](request: Request[A]): Option[Subject] =
    Await.result(userService.getUser(request), 1.minute)) // This code is blocking
}

So, were there any purpose for forcing users to block their service calls?

[Steve Chaloner]

I had to pull out the Future parts of the code because of a design issue that was impacting the view layer. 2.3.2 is functionally identical to 2.3.3, but does allow you to return a Future from getSubject - I suggest you stick with this.

v2.4 will have a different approach that fixes the view-level issues, but is non-blocking elsewhere. There's a discussion of this on StackOverflow.

[Denis Borisenko]

Ok, I'll keep using 2.3.2 then. Thanks for the fast answer.