I believe we may have made a mistake in locating the @RequestScoped and
@SessionScoped annotations in com.google.inject.servlet.  The concepts they represent
should not have been tied to the servlet concept.  Our ServletScopes implementations
for these are servlet-specific, of course.  But this would let you bind those same
annotations to whatever you please without having to import from
com.google.inject.servlet.

Still, I don't know what we can do about this now.

I suppose the best we can do is fix the documentation on those two annotations and
move them to the main jar file.  But we can't change the package. :(

Do we really need "request" and "session" scope outside of a web application?

Why wouldn't we?  Perhaps it just has an RMI or other RPC interface.  And perhaps it
wants to reuse modules that are also used by a web front-end.  It sounds totally
plausible to me.  How or why they'd use Session is a mite questionable, of course.

When I said "really," I meant "really," as in does somebody really need this badly
enough to futz up the API? Because if they do, we will. I'm not sure "request" is the
right word for RPC calls anyway.

I personally need request and thread scopes to be the same. I don't have an issue
with session (I included it for generality only). Our web application (probably
others also) has a scheduler to execute tasks. Much of the code used in tasks is
common to http requests. I.e. there is not much difference between request performing
certain actions and a scheduler thread performing other actions. In fact most of the
code is Servlet unaware.

+1 for the addition of a thread scope. I also created my own, so that makes two...
I use it to scope objects in a per request security context. To make my code work in 
a standalone scenario, I can't live without that thread scope. I'll take a look if I 
can donate some of my code, but it obviously looks similar to cquezel's.

I wouldn't bother with session scope either.

My code attached, including simple unit test. Feedback appreciated.

	GuiceThreadScope.txt
	5.8 KB Download

Blogged about it (includes code example):
http://garbagecollected.wordpress.com/2007/06/07/guice-thread-scope/

Guice is very flexible, you can add any scope you want.

Wait a minute -- you say "thread scope", but then you say "per request".  Which is
it?  Is it a request scope, or a thread scope?  A "thread scope" would be something
that lives for the entire lifetime of the thread.

It could be both, actually. If you don't reset it, it lives as long as the thread, 
and if you do, it could live as long as a request. Pure thread scoping probably 
isn't always what you want if you do thread pooling (or if your ejb/web/whatever 
container does). So the scope is thread, or less. Does that make sense?

Maybe the upcoming conversation scope addresses some of this? (the "or less" part?)

I don't think there's any value in the concept of "resetting" a scope.  If you want
it to live as long as the thread does (e.g. you just want to reuse SimpleDateFormat
instances), that's thread scope; if you want the lifetime to be shorter, you want
your own Request or Job or Task or UnitOfWork or Foo scope.

Thanks Kevin: you're right. What I implemented is a UnitOfWork scope that, in my 
specific scenario, is able to replace the HTTP Request scope. And if you don't use 
the reset() method in my code, it will behave exactly like a thread scope.

I gave all this some more thought, and I agree that it doesn't make sense to add an 
HTTP Request scope replacement to Guice. What we need is a Conversation scope that 
isn't web specific. How will you guys implement Conversation scope?

Thread scope could still be useful, and perhaps we should raise a new issue for that 
one.

Created  issue #100  for the Thread scope thing.

Argh..  issue #114 , I mean.

I've been able to get rid of my use case for this issue, after changing my
application to use pure Thread scope as implemented in  issue #114 .

First, I define an interface like this:

public interface GuiceCallable<V> {
    public V call(Injector injector);
}

And then I use a template class that creates a thread per method invocation:

public class GuiceTemplate {
    ...
    public <V> V call(final GuiceCallable<V> c) {
        Future<V> future = Executors.newSingleThreadExecutor().submit(
            new Callable<V>() {
                public V call() {
                    return c.call(this.injector);
                }
            }
        );
        try {
            return future.get();
        } catch (InterruptedException e) {
            ...
        } catch (ExecutionException e) {
            ...
        }
    }
}

So I guess this is an extra use case for  issue #114 .

I think this issue can be closed.

My summary:
- HTTP Request scope can be replaced by using THREAD scope. The only caveat I spot 
is when one creates threads within the template; people who need that could 
implement their own THREAD scope with InheritableThreadLocal, or create a custom 
solution.
- An HTTP Session scope replacement is probably less important. For a lot of 
standalone (as in Swing, ...) applications, SINGLETON will do just fine because only 
one application instance will run at a time in a single JVM.
- As for the Conversation scope for non web apps (which I mentioned), it will be 
hard to implement a solution that is generic enough for most people to use. But it 
would be really, really cool.

Migration from HTTP to THREAD/... can be as easy as replacing some bindings, and 
perhaps rewriting one class. That's not too bad.

Robbie summarized this nicely. We're going to leave everything as-is.  Issue 114  will cover thread scope, 
inheritable thread scope etc., and whether they should be included.

I think the best takeaway on this issue is that we should write a how-to doc that walks through implementing a 
custom scope.