That's a nice technique. Thanks for sharing that. For shindig's use of Guice this plus an InhertiableThreadLocal could solve most Request Scoped issues, since we maintain our own Guice- injected Executor that could be wrapped as you have done.
The only remaining issue I can see is thread-safeness. Many of the things we might inject are mutable and may not be thread safe. Thanks! On Aug 5, 12:41 pm, Tim Peierls <[email protected]> wrote: > On Aug 3, 9:16 pm, Paul Lindner <[email protected]> wrote: > > > I've been looking into Reqest Scopes and GuiceFilter and noticed that > > it uses a ThreadLocal to store the request state. This works fine for > > single threaded request/response model. However if an application > > uses a cached thread pool or child threads then injection is not > > possible. > > > Is there a solution in the works for this situation? An > > InheritableThreadLocal would suffice for threads created by the > > request thread -- however using something like > > Executors.newCachedThreadPool(); would not. > > On Aug 3, 9:16 pm, Paul Lindner <[email protected]> wrote: > > > I've been looking into Reqest Scopes and GuiceFilter and noticed that > > it uses a ThreadLocal to store the request state. This works fine for > > single threaded request/response model. However if an application > > uses a cached thread pool or child threads then injection is not > > possible. > > > Is there a solution in the works for this situation? An > > InheritableThreadLocal would suffice for threads created by the > > request thread -- however using something like > > Executors.newCachedThreadPool(); would not. > > There are several ways to pass ThreadLocal-ly held state across the > ExecutorService.execute boundary, all involving some kind of usage > restriction. > > For example, the Restlet framework has several per-request values that > threads running in a thread pool might need access to. Restlet's > TaskService class lets you wrap a regular ExecutorService with a > decorator that passes these values through. I'm not saying this is > often (or even ever) a good thing to do; I'm just illustrating the > technique. Here's the code that accomplishes this, in the wrap() > method: > > http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#XauSBc5aprQ/... > > --tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
