Brian - you can create request scoped variables by calling: bind(Foo.class).to(Bar.class).in(RequestScoped.class);
Request scoping may also automatic if your constructor takes a RequestScoped object. For example, AuthInfo takes an HttpServletRequest as a constuctor arg, so by default it is scoped to the request. Kevin - we can create our own request scope type that matches our logical request scope. Separate thread for processing doesn't prevent request-scoped injection, just means that you have to do more work. The alternative of passing all parameters that any class needs anywhere down the call chain on the SecurityToken seems to be an unscalable design. Evan On Fri, Oct 3, 2008 at 1:50 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Thu, Oct 2, 2008 at 10:56 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 2, 2008 at 9:34 PM, Evan Gilbert <[EMAIL PROTECTED]> wrote: > > > Request scoped Guice variables handle this much more > > > cleanly. > > > > Do you have some example code for this? Would it work something like > this: > > > > - SecurityTokenDecoder verifies token, sticks verified token in ether > > fully typed > > - Code running later on in request processing magically pulls token > > (as full type) out of ether > > > > Setting credentials as thread-local is sometimes used for this kind of > > thing, but I can't see that working for something that uses thread > > pools as much as Shindig. > > > And, in fact, it doesn't work because HTTP request processing is frequently > done on a separate thread from the one processing the request. >
