Hi Bob, So would you say I shouldn't worry about the cost of creating child injectors on every request? I sort of like this approach. Having to transfer state between thread locals seems error-prone.
The only thing I don't like is I can't "override" bindings in the child injector from the parent injector, unless I also do it using another scope or a inject different type. Greg On Tue, Dec 20, 2016 at 11:15 AM, Bob Lee <[email protected]> wrote: > Child injectors were designed in part for this very use case! If child > injectors had been in 1.0, we probably wouldn't have scopes. > > Bob > > On Mon, Dec 19, 2016 at 11:36 PM, Greg Methvin <[email protected]> > 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/google-guice. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/google-guice/7494eddd-a7ea-4351-965a-2b3d96c8f14f%40googlegroups.com >> <https://groups.google.com/d/msgid/google-guice/7494eddd-a7ea-4351-965a-2b3d96c8f14f%40googlegroups.com?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 a topic in the > Google Groups "google-guice" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/google-guice/qZqkaWPkhoo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > 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/CAGmsiP48Vfsn8v-x18j1Um-JnNXmovi2wg52uPM1M52bToabcA% > 40mail.gmail.com > <https://groups.google.com/d/msgid/google-guice/CAGmsiP48Vfsn8v-x18j1Um-JnNXmovi2wg52uPM1M52bToabcA%40mail.gmail.com?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 [email protected]. To post to this group, send email to [email protected]. 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/CAO2h8AzLuOL%3DZteePgD82XUhuwuObRxFsd8r9obdHt954BU4%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
