Hi.
Yes, the custom scope example on the page do not solve the problem. To be
more explicit on my proposition, the enterRequest method on a different
scope may look like this:
class CustumMultiRequestPerThreadScope extends Scope {
private volatile ThreadLocal<Map<Key<?>, Object>>
currentRequestInjectionResults = null;
public void enterRequest(CustomFrameworkRequestInfo requestData) {
currentRequestInjectionResults = requestData.getInjectionResults();
}
}
Here currentRequestInjectionResults is ThreadLocal only to allow a single
instance of the scope implementation, but in each thread You need to enter
and exit the request data "During the time that the thread calculations are
working on a specific request" - this is the key.
On Tue, Dec 20, 2016 at 10:52 AM, Stephan Classen <st.clas...@gmx.ch> wrote:
> This does not solve the problem. The custom scope example uses a
> ThreadLocal<Map<Key<?>, Object>> to store the scoped values. I am currently
> also looking for a "RequestScope" in an environment where a request may be
> handled by more than one thread.
>
> On 20.12.2016 08:57, Paweł Cesar Sanjuan Szklarz wrote:
>
> Hi.
>
> If the request dependencies are created in a specific moment on time in a
> single thread, then You can make a custom scope to setup the correct
> request context.
>
> The basic scope idea is that You create a specialized provider from a more
> general one:
> https://github.com/google/guice/blob/36542433938113806c8d1e3e4b41c6
> 4d9b8a0dca/core/src/com/google/inject/Scope.java#L44
>
> Just like on the example of custom scope:
> https://github.com/google/guice/wiki/CustomScopes#triggering-the-scope
>
> You can trigger/setup the scope implementation to provide the correct
> provider.
>
> A example of scope use in a single thread for multiple request may be:
> for (int i = 0; i < workAndData.length; i++) {
> workAndData = workAndData[i];
> scope.enterRequest(workAndData.getRequest());
> workAndData.runJob();
> scope.exitRequest();
> }
>
> Of course You need to setup the scope in every thread where the request
> scope will be used.
>
> Pawel.
>
> On Tue, Dec 20, 2016 at 8:36 AM, Greg Methvin <greg.meth...@gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> I currently one of the maintainers of Play Framework, a Java/Scala web
>> framework that integrates with Guice. Play uses non-blocking I/O, and since
>> one thread may handle multiple requests at once, we can't use thread locals
>> to scope dependencies.
>>
>> So I'm wondering if there is a recommended way to bind instances only in
>> the context of a particular object (like a request) without using any
>> global or thread-local state.
>>
>> I can basically do what I want by creating a child injector for each
>> request. The child injector also binds the request and a module with
>> request-scoped dependencies. It then uses that injector to obtain an
>> instance of the relevant controller to handle the request, which may have
>> dependencies bound that use the request instance. Of course that means you
>> need to create a new child injector per request, which doesn't seem like a
>> good idea.
>>
>> Does it make sense to use Guice to solve this problem? Is there a better
>> way to do it than what I've tried?
>>
>> Thanks,
>> Greg
>> --
>> You received this message because you are subscribed to the Google Groups
>> "google-guice" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-guice+unsubscr...@googlegroups.com.
>> To post to this group, send email to <google-guice@googlegroups.com>
>> google-guice@googlegroups.com.
>> Visit this group at https://groups.google.com/group/google-guice.
>> To view this discussion on the web visit
>> <https://groups.google.com/d/msgid/google-guice/7494eddd-a7ea-4351-965a-2b3d96c8f14f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> https://groups.google.com/d/msgid/google-guice/7494eddd-a7ea
>> -4351-965a-2b3d96c8f14f%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-guice+unsubscr...@googlegroups.com.
> To post to this group, send email to google-guice@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-guice.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/google-guice/CAGReoCQhkV-FrJoo-K%3DkXvmC-2WSBcPVg8Ogyt6dtPoj-b6P%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> https://groups.google.com/d/msgid/google-guice/
> CAGReoCQhkV-FrJoo-K%3DkXvmC-2WSBcPVg8Ogyt6dtPoj-b6P%3DA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-guice+unsubscr...@googlegroups.com.
> To post to this group, send email to google-guice@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-guice.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-guice/b5e469fd-1789-110d-f589-30e6a0bcb5c5%40gmx.ch
> <https://groups.google.com/d/msgid/google-guice/b5e469fd-1789-110d-f589-30e6a0bcb5c5%40gmx.ch?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@googlegroups.com.
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/CAGReoCQ%2Bzt%3DH65mtJjQO3cbczDY6kturWhJ4bNbaJXxQBiWqVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
