Open GoogleCodeExporter opened 9 years ago
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.
Original comment by kevin...@gmail.com
on 15 May 2007 at 4:57
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. :(
Original comment by kevin...@gmail.com
on 3 Jun 2007 at 6:34
Do we really need "request" and "session" scope outside of a web application?
Original comment by crazybob...@gmail.com
on 3 Jun 2007 at 6:41
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.
Original comment by kevin...@gmail.com
on 3 Jun 2007 at 6:48
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.
Original comment by crazybob...@gmail.com
on 3 Jun 2007 at 7:00
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.
Original comment by cque...@gmail.com
on 5 Jun 2007 at 5:56
+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.
Original comment by robbie.v...@gmail.com
on 6 Jun 2007 at 7:49
My code attached, including simple unit test. Feedback appreciated.
Original comment by robbie.v...@gmail.com
on 7 Jun 2007 at 11:40
Attachments:
Blogged about it (includes code example):
http://garbagecollected.wordpress.com/2007/06/07/guice-thread-scope/
Original comment by robbie.v...@gmail.com
on 7 Jun 2007 at 12:37
Guice is very flexible, you can add any scope you want.
Original comment by feng.ronald@gmail.com
on 7 Jun 2007 at 12:45
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.
Original comment by kevin...@gmail.com
on 7 Jun 2007 at 4:28
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?)
Original comment by robbie.v...@gmail.com
on 7 Jun 2007 at 5:09
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.
Original comment by kevin...@gmail.com
on 7 Jun 2007 at 5:34
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.
Original comment by robbie.v...@gmail.com
on 7 Jun 2007 at 6:41
Created issue #100 for the Thread scope thing.
Original comment by robbie.v...@gmail.com
on 8 Jun 2007 at 10:27
Argh.. issue #114, I mean.
Original comment by robbie.v...@gmail.com
on 8 Jun 2007 at 10:28
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.
Original comment by robbie.v...@gmail.com
on 11 Jun 2007 at 2:50
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.
Original comment by robbie.v...@gmail.com
on 11 Jun 2007 at 10:04
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.
Original comment by limpbizkit
on 31 May 2008 at 7:23
Original issue reported on code.google.com by
cque...@gmail.com
on 4 May 2007 at 1:49