Servlet context scope

[GoogleCodeExporter]

For certain classes it can be useful to have access to
javax.servlet.ServletContext and even wire objects in a ServletContext
scope, just as it can be useful to wire them in Session or Request scope.

I've created a trivial patch to implement the requested feature. It's
fairly simple and gives classes in the scope the ability to @Inject
javax.servlet.ServletContext.

The only flaw I can think of is that I use static member on the class to
store the javax.servlet.ServletContext instance which *shouldn't* be a
problem since the there should only be one instance of the
GuiceServletContextListener per web application and the static field is
isolated per deployed context.

Feedback and opinions are welcome. Diff file is created with a simple "svn
diff".

Original issue reported on code.google.com by arn...@gmail.com on 19 Aug 2008 at 11:43

Attachments:

• servletcontext.patch

[GoogleCodeExporter]

Just a quick note: This is not a defect -- it's a trivial feature.

Original comment by arn...@gmail.com on 22 Aug 2008 at 12:10

[GoogleCodeExporter]

Ooops. Forgot to add the ServletContextScoped @interface to subversion before 
running
diff. Fixed in the new attachment.

Original comment by arn...@gmail.com on 1 Sep 2008 at 12:55

Attachments:

• servletcontext2.patch

[GoogleCodeExporter]

Original comment by limpbizkit on 2 Nov 2008 at 9:15

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I'm not sure I understand how this is different from singleton scope? In the 
patch, the servletcontext is stored in 
a static field anyway...

Original comment by dha...@gmail.com on 28 Nov 2008 at 8:18

[GoogleCodeExporter]

Well, you can't inject javax.servlet.ServletContext into a singleton (if I 
remember
correctly). You'd have to use a Provider, which isn't bad, it just isn't 
obvious for
the most basic users. Perhaps documenting the case, and letting users know that 
they
mustn't attempt to access the ServletContext instance unless the code is 
actually run
inside a request.

With my patch you could've accessed the ServletContext instance as soon as the
application was initialized, since the class it was injected to would've been 
bound
to the scope of the web application.

Hope my intentions are clear.

Original comment by arn...@gmail.com on 30 Dec 2008 at 3:28

[GoogleCodeExporter]

OK I believe the Provider is an acceptable compromise in this case, since it 
will throw an OutOfScopeException if 
accessed outside a request anyway.

Closing this bug.

Original comment by dha...@gmail.com on 31 Jan 2009 at 5:38

• Changed state: WontFix