This could eventually be used as an alternative to Http.Context in Java, but to do that we'd need to refactor how the context is created. Right now it's done inside the JavaAction.

Great!

It will work as expected with the HttpRequestHandler and other components. If I understand it properly, the router still a singleton, but it will "fabricate" a new one for each request. And then, for each new "fabricated" Router we will get new controllers instances.

But, if the controllers are annotated with @Singleton, they will be reused (I suppose createChildInjector inherits the state of the parent Injector).

Will it have any (negative) impact on performance?

Will it have any (negative) impact on performance?

The main concern I have is the performance impact creating a child injector. I tried looking at using a Scope in Guice, but it seems the built-in SimpleScope is thread-based. Maybe we need to do some benchmarks and see.

The cost of creating new instances is not really a problem. Normally it only makes sense to use @Singleton if your class has state, or if it is very expensive to create.

Looking at this validator class does it mean we could just inject a component (like we do with messagesApi) to replace Http.Context.current.get()? That would be awesome, specially since there is now way to pass the current context into the isValid method of a validator.

Also we could inject such components into the HttpErrorHandler (?)

@mkurz Actually, it wouldn't work as I wrote it right now, because the JavaHandlerComponents doesn't use the request-scoped injector. I think it would work if we created an HttpRequestHandler on each request. That would also allow you to bind the request in your HttpErrorHandler implementation.

It seems like child injectors are the right way to achieve what we want to do (see https://groups.google.com/d/msg/google-guice/qZqkaWPkhoo/tcCRWNmIDQAJ).

One issue is that child injectors can't override bindings from the parent module, but we can't access the request unless the binding was in a request scoped module. So we probably have to separate out the request-scoped things into a separate Play module, so we can bind them only in the child injector.

Closing since this is not likely to happen, at least not in this form. If someone wants to pick this up and continue working on it, it should be possible to do it in another project. It's also possible you could make a request-scoped HttpRequestHandler instead.