Are Http scopes and scope implementations sufficiently general? #100
Comments
|
From kevinb9n on May 15, 2007 09:57:25 I believe we may have made a mistake in locating the Still, I don't know what we can do about this now. Status: Accepted |
|
From kevinb9n on June 03, 2007 11:34:38 I suppose the best we can do is fix the documentation on those two annotations and |
|
From crazyboblee on June 03, 2007 11:41:51 Do we really need "request" and "session" scope outside of a web application? |
|
From kevinb9n on June 03, 2007 11:48:05 Why wouldn't we? Perhaps it just has an RMI or other RPC interface. And perhaps it |
|
From crazyboblee on June 03, 2007 12:00:37 When I said "really," I meant "really," as in does somebody really need this badly |
|
From cquezel on June 05, 2007 10:56:25 I personally need request and thread scopes to be the same. I don't have an issue |
|
From robbie.vanbrabant on June 06, 2007 12:49:29 +1 for the addition of a thread scope. I also created my own, so that makes two... I wouldn't bother with session scope either. |
|
From robbie.vanbrabant on June 07, 2007 04:40:32 My code attached, including simple unit test. Feedback appreciated. Attachment: gist |
|
From robbie.vanbrabant on June 07, 2007 05:37:02 Blogged about it (includes code example): http://garbagecollected.wordpress.com/2007/06/07/guice-thread-scope/ |
|
From feng.ronald on June 07, 2007 05:45:19 Guice is very flexible, you can add any scope you want. |
|
From kevinb9n on June 07, 2007 09:28:30 Wait a minute -- you say "thread scope", but then you say "per request". Which is |
|
From robbie.vanbrabant on June 07, 2007 10:09:29 It could be both, actually. If you don't reset it, it lives as long as the thread, Maybe the upcoming conversation scope addresses some of this? (the "or less" part?) |
|
From kevinb9n on June 07, 2007 10:34:06 I don't think there's any value in the concept of "resetting" a scope. If you want |
|
From robbie.vanbrabant on June 07, 2007 11:41:54 Thanks Kevin: you're right. What I implemented is a UnitOfWork scope that, in my I gave all this some more thought, and I agree that it doesn't make sense to add an Thread scope could still be useful, and perhaps we should raise a new issue for that |
|
From robbie.vanbrabant on June 08, 2007 03:27:50 Created issue #100 for the Thread scope thing. |
|
From robbie.vanbrabant on June 08, 2007 03:28:53 Argh.. issue #114 , I mean. |
|
From robbie.vanbrabant on June 11, 2007 07:50:08 I've been able to get rid of my use case for this issue, after changing my First, I define an interface like this: public interface GuiceCallable<V> { And then I use a template class that creates a thread per method invocation: public class GuiceTemplate { So I guess this is an extra use case for issue #114 . |
|
From robbie.vanbrabant on June 11, 2007 15:04:22 I think this issue can be closed. My summary:
Migration from HTTP to THREAD/... can be as easy as replacing some bindings, and |
|
From limpbizkit on May 31, 2008 12:23:44 Robbie summarized this nicely. We're going to leave everything as-is. Issue 114 will cover thread scope, I think the best takeaway on this issue is that we should write a how-to doc that walks through implementing a Status: WontFix |
From cquezel on May 03, 2007 21:49:09
Are Http scopes and scope implementations sufficiently general?
I am very new to Guice so what I am proposing here may not be correct ...
but here it goes.
I was looking at the scope features (doc please ...) to figure how I could
use scopes in my applications. I noticed that the REQUEST and SESSION
scopes are very http Servlet oriented. I was wondering if this was
necessary.
I think that non http Servlet based application could benefit from general
purpose REQUEST and SESSION scopes. Http Servlet based application could
also benefit from this. So I am proposing create more general REQUEST and
SESSION scopes and to use these to implement http Servlet scoping.
First, I would define a general purpose class for thread based scope to
take over the non http Servlet API part of the GuiceFilter class. For
example:
public final class RequestScopeSetter {
private RequestScopeSetter()
{
// Hide
}
private static final ThreadLocal<Map<String, Object>> REQUEST_CACHE
= new ThreadLocal<Map<String, Object>>();
public static void beginScope()
{
REQUEST_CACHE.set(new HashMap<String, Object>());
}
public static void endScope()
{
REQUEST_CACHE.set(null);
}
static Map<String, Object> getCache() {
Map<String, Object> cache = REQUEST_CACHE.get();
if (cache == null) {
throw new IllegalStateException(
"Cannot access request scoped object. " +
"Either we are not currently inside a " +
"scoped thread, or you may have forgotten " +
"to initialize the thread with " +
RequestScopeSetter.class.getName() +
".beginScope() method."
);
}
return cache;
}
}
Next I would modify the Filter class to use this mechanism (or define
another Filter):
public void doFilter(ServletRequest servletRequest,
ServletResponse servletResponse, FilterChain filterChain)
throws IOException, ServletException {
Context previous = localContext.get();
try {
localContext.set(new Context((HttpServletRequest) servletRequest,
(HttpServletResponse) servletResponse));
RequestScopeSetter.beginScope();
try {
filterChain.doFilter(servletRequest, servletResponse);
} finally {
RequestScopeSetter.endScope();
}
} finally {
localContext.set(previous);
}
}
I would maybe define a Runnable for other uses:
class RequestScopeSetterRunnable implements Runnable {
private final Runnable toRun;
RequestScopeSetterRunnable(Runnable toRun)
{
this.toRun = toRun;
}
public void run()
{
RequestScopeSetter.beginScope();
try {
toRun.run();
} finally {
RequestScopeSetter.endScope();
}
}
}
The REQUEST scope would be implemented as:
final class Scopes {
public static final Scope REQUEST = new Scope() {
public <T> Provider<T> scope(Key<T> key,
final Provider<T> creator) {
final String name = key.toString();
return new Provider<T>() {
public T get() {
Map<String, Object> threadCache
= ThreadScopeSetter.getCache();
synchronized (threadCache) {
@SuppressWarnings("unchecked")T t = (T) threadCache.get(name);
&nbs...
Original issue: http://code.google.com/p/google-guice/issues/detail?id=100
The text was updated successfully, but these errors were encountered: