The important thing to keep in mind about scoping is that a key is bound under a scope, not an object or class. This is true of any scope, not just the singleton. Take the following example of a master terminal that can see several security cameras in a building:

<bean id="terminal" class="MasterTerminal" scope="singleton"/>

<bean id="camera.basement" class="SimpleCamera" scope="prototype">
    <constructor-arg ref="terminal"/>
</bean>

<bean id="camera.penthouse" class="SimpleCamera" scope="prototype">
    <constructor-arg ref="terminal"/>
</bean>

Notice that I explicitly declare terminal as a singleton (by default, Spring beans are all singletons) and both cameras as no scoped (scope="prototype"). In this configuration, both camera.basement and camera.penthouse share the same instance of MasterTerminal. Any further keys will also share this instance. Consider this equivalent in Guice, using a module:

Here we use combinatorial keys (see chapter 2) to identify the basement and penthouse security cameras. Since Guice binds keys under no scope by default, we need only scope MasterTerminal:

bind(MasterTerminal.class).in(Singleton.class);

This has the same semantics as the Spring configuration. All security camera instances share the same instance of MasterTerminal, as shown in figure 5.11.

Another option is to directly annotate MasterTerminal as a singleton:

This lets you skip an explicit binding (see BuildingModule). Figure 5.12 shows how a singleton-scoped instance is shared among no-scoped objects.

Figure 5.11. Keys are bound under scopes, rather than classes or objects<br></br> 

Figure 5.12. A singleton-scoped instance injected into many no-scoped instances<br></br> 

To further illustrate the difference between no scope and singleton scope, let's examine another interesting case. Here is a class BasementFloor, which represents a part of the building where security cameras may be installed:

public class BasementFloor {
    private final Camera camera1;
    private final Camera camera2;

    @Inject
    public BasementFloor(@Basement Camera camera1,
                         @Basement Camera camera2) {

        this.camera1 = camera1;
         this.camera2 = camera2;

    }
}

You might expect that both camera1 and camera2 refer to the same instance of security camera, that is, the one identified by key [Camera, Basement]. But this is not what happens—camera1 and camera2 end up with two different instances of Camera. This is because the key [Camera, Basement] is bound to no scope (see figure 5.13).

Figure 5.13. BasementFloor is wired with two separate instances of no-scoped key [Camera, @Basement].<br></br> 

Similarly, any dependents of [Camera, Penthouse] will end up with new, unrelated instances of Camera. Consider another class, Building, which houses more than one kind of camera:

public class Building {
    private final Camera camera1;
    private final Camera camera2;
    private final Camera camera3;
    private final Camera camera4;

    @Inject
    public Building(@Basement Camera camera1,

@Basement Camera camera2,
                    @Penthouse Camera camera3,
                    @Penthouse Camera camera4) {

         this.camera1 = camera1;
         this.camera2 = camera2;
         this.camera3 = camera3;
         this.camera4 = camera4;
    }
}

Here, all four fields of Building receive different instances of Camera even though only two keys are present. This is opposed to the following class, ControlRoom, which has four fields that refer to the same instance of MasterTerminal but via four references (modeled in figure 5.14):

public class ControlRoom {
    private final MasterTerminal terminal1;
    private final MasterTerminal terminal2;
    private final MasterTerminal terminal3;
    private final MasterTerminal terminal4;

    @Inject
    public ControlRoom(MasterTerminal terminal1,
                  MasterTerminal terminal2,
                  MasterTerminal terminal3,
                  MasterTerminal terminal4) {

        this.terminal1 = terminal1;
        this.terminal2 = terminal2;
        this.terminal3 = terminal3;
        this.terminal4 = terminal4;
    }
}

Figure 5.14. All four fields of ControlRoom are wired with the same instance of MasterTerminal.<br></br> 

If we added a new kind of MasterTerminal, bound to a different key, then this would be a different instance. Let's say I add a MasterTerminal for the basement only:

Now any dependents of [MasterTerminal, Master] see the same shared instance, but any dependents of key [MasterTerminal, Basement] see a different instance. The modified version of Building in listing 5.2 illustrates this situation.

Example 5.2. Object with two different singleton-scoped dependencies

In listing 5.2, terminal1 and terminal2 share the same instance of MasterTerminal. But terminal3 and terminal4 share a different instance. I belabor this point because it is very important to distinguish that a key, rather than an object, is bound under a scope. Singleton scoping allows many instances of the same class to exist and be used by dependents; it allows only one shared instance of a key. This is quite different from the conventional understanding of singletons. This idiom implies a more absolute single instance per application and is definitely problematic. In the following section I'll explain why I go so far as to call it an anti-pattern when compared with the much more erudite singleton scope.

You have probably heard a lot of discussion around the web and in technical seminars about the horrors of the singleton as an anti-pattern. Earlier we drew a distinction between singleton scope, a feature of DI, and singleton objects (or singleton anti-patterns), which are the focus of much of this debate. The singleton anti-pattern has several problems. Compounding these problems is the fact that singletons are very useful and therefore employed liberally by developers everywhere.

Its problems however, greatly outweigh its usefulness and should warn you off them for good (especially when dependency injection can save the day with singleton scoping). Let's break this down in code:

public class Console {
    private static Console instance = null;

    public static synchronized Console getInstance() {

if (null == instance)
            instance = new Console();

        return instance;
    }

    ...
}

I'm sure you have seen or written code like this. I certainly have. Its purpose is quite simple; it allows only one instance of Console ever to be created for the life of the program (representing the one monitor in a computer, for example). If an instance does not yet exist, it creates one and stores it in a static variable instance:

if (null == instance)
    instance = new Console();

return instance;

The static getInstance() method is declared synchronized so that concurrent threads don't accidentally attempt to create instances concurrently. In essence, getInstance() is a Factory method—but a special type of Factory that produces only one instance, thereafter returning the stored instance every time. You might say this is the Factory equivalent of singleton scoping.

Apart from all the foibles that Factories bring, note that this immediately causes one major problem. This code is not conducive to testing. If an object relies on Console.getInstance() to retrieve a Console instance and print something to it, there is no way for us to write a unit test that verifies this behavior. We cannot pass in a substitute Console in the following code:

public class StockTicker {
    private Console console = Console.getInstance();

    public void tick() {
        //print to console
        ...
    }
}

StockTicker directly retrieves its dependency from the singleton Factory method. In order to test it with a mock Console, you'd have to rewrite Console to expose a setter method:

public class Console {
    private static Console instance = null;

    public static synchronized Console getInstance() {
        if (null == instance)
            instance = new Console();

        return instance;
    }

    public static synchronized void setInstance(Console console) {
        instance = console;

}
    ...
}

Patterns that force you to add extra code or infrastructure logic purely for the purposes of testing are poor servants of good design. Nonetheless, now you can test StockTicker:

public class StockTickerTest {

    @Test
    public final void printToConsole() {
        Console.setInstance(new MockConsole());
        ...
    }
}

But what if there are other tests that need to create their own mocked consoles for different purposes (say, a file listing service)? Leaving the mocked instance in place will clobber those tests. To fix that, we have to change the test again:

public class StockTickerTest {

    @Test
    public final void printToConsole() {
        Console previous = Console.getInstance();
        try {
            Console.setInstance(new MockConsole());
            ...
        } finally {
            Console.setInstance(previous);
        }
    }
}

I wrapped the entire test in a try/finally block to ensure that any exceptions thrown by the test do not subvert the Console reset.

public class StockTickerTest {
    private Console previous;
    @BeforeMethod
    void setup() {

previous = Console.getInstance();
    }
    @Test
    public final void printToConsole() {
        Console.setInstance(new MockConsole());
        ...
    }
    @AfterMethod
    void teardown() {
        Console.setInstance(previous);
    }
}

This is a lot of boilerplate to write just to get tests working. It gets worse if you have more than one singleton dependency to mock. Furthermore, if you have many tests running in parallel (in multiple threads), this code doesn't work at all because threads may crisscross and interfere with the singleton. That would make all your tests completely unreliable. This ought to be a showstopper.

If you have more than one injector in an application, the situation grows worse. Singleton objects are shared even between injectors and can cause a real headache if you are trying to separate modules by walling them off in their own injectors (see figure 5.15).

Figure 5.15. Singleton-patterned objects are shared even across injectors.<br></br> 

Moreover, any object created and maintained outside an injector does not benefit from its other powerful features, particularly lifecycle and interception—and the Hollywood Principle. One of the great benefits of DI is that it allows you to quickly bind a key to a different scope simply by changing a line of configuration. That's not possible with the singleton object (figure 5.16).

Its class must be rewritten and retested to introduce scoping semantics. Refactoring between scopes is also a vital part of software development and emerging design. Singleton objects hinder this natural, iterative evolution.

So to sum up: singleton objects bad, singleton scoping good. Singleton objects make testing difficult if not impossible and are antithetical to good design with dependency injection. Singleton scoping, on the other hand, is a purely injector-driven feature and completely removed from the class in question (figure 5.17).

Figure 5.16. Singleton anti-pattern objects sit outside dependency injectors.<br></br> 

Singleton scope is thus flexible and grants the usefulness of the Singleton antipattern without all of its nasty problems. Scopes have a variety of other uses; they needn't only be applied in the singleton and no scope idioms. In web applications, scopes are extremely useful as unintrusive techniques in maintaining user-specific state. These web-specific scopes are explored in the following section.

Figure 5.17. Singleton-scoped objects are well-behaved and live inside the injector.<br></br> 

The request scope is interesting because it isn't strictly a segment in the life of an injector. Since requests can be concurrent, request scopes are also concurrent (but disparate from one another). Let's take the example of an online comic book store. Sandman is one of my favorite books, so I do a search for Sandman by typing in "sandman" at the appropriate page. To the comics store, this is a request for a document containing a list of Sandman titles. Let's call the service that generates this document ComicSearch. ComicSearch must

Let's make another service that accesses the database and call this ComicAccess. ComicAccess will in turn depend on database-specific services like connections and statements in order to deliver results. Listing 5.4 describes the code for the comic store so far.

public class ComicSearch {
    private final ComicAccess comicAccess;

    @Inject
    public ComicSearch(ComicAccess comicAccess) {
        this.comicAccess = comicAccess;
    }

    public HTML searchForComics(String criteria) {
        ...
    }
}

Now it makes sense for the ComicAccess object to be a singleton—it has no state, connects to a database as needed, and will probably be shared by several clients (other web pages needing to access the comic store). The searchForComics() method takes search criteria (typed in by a user) and returns an HTML object.

ComicSearch is itself stateless (since its only dependency, ComicAccess, is immutable), so we could bind it as a singleton. Given this case, it actually works quite well. Since there is no request-specific context, binding ComicSearch either as a singleton or no scope is viable.

Let's expand this example. Let's say we add a requirement that the store shows me items of interest based on my prior purchases. It's not important how it determines my interests, just that it does. Another service, UserContext, will handle this work:

public class UserContext {
    private String username;

    private final ComicAccess comicAccess;

    @Inject
    public UserContext(ComicAccess comicAccess) {
        this.comicAccess = comicAccess;
    }

    public List<Comic> getItemsOfInterest() {
        ...
    }
    public void signIn(String username) {
        this.username = username;


    }
}

The method getItemsOfInterest()scans old purchases using ComicAccess and builds a list of suggestions. The interesting part about UserContext is its field username and method signIn():

public void signIn(String username) {
    this.username = username;
}

When called with an argument, signIn() stores the current user. You'll notice that signIn() is more or less a setter method. But I've deliberately avoided calling it setUsername() to distinguish it from a dependency setter. signIn() will be called from ComicSearch, which itself is triggered by user interaction. Here's the modified code from listing 5.4, reflecting the change:

public class ComicSearch {
    private final ComicAccess comicAccess;
    private final UserContext user;

    @Inject
    public ComicSearch(ComicAccess comicAccess, UserContext user) {
        this.comicAccess = comicAccess;
        this.user = user;
    }

    public HTML searchForComics(String criteria, String username) {
        user.signIn(username);

        List<Comic> suggestions = user.getItemsOfInterest();

        ...
    }
}

ComicSearch is triggered on a request from a user, and method searchForComics() is provided with an additional argument, username, also extracted from the HTTP request. The UserContext object is configured with this username. Now any results it returns will be specific to the current user.

Let's put the UserContext to work and expand this another step. We'll add a requirement that the list of results should not show any comics that a user has already purchased. One way to do this is with two queries, one with the entire set of results and the second with a history of purchases, displaying only the difference. That sequence would be:

This works, but it seems awfully complex. It is a lot of code to write and a bit superfluous. Furthermore, if these sets are reasonably large and contain a lot of overlap, it could mean doing a large amount of work to bring up results that are simply thrown away. Worse, two queries are two trips to the database, which is expensive and unnecessary in a high-traffic environment.

Another solution is to create a special finder method on ComicAccess that accepts the username and builds a database query sensitive to this problem. This is much better, because only the relevant results come back and the impact to ComicSearch is very small:

But we can do one better. By moving this work off to UserContext, it avoids ComicSearch having to know the requisite details for querying comics:

public class UserContext {
    private String username;

    private final ComicAccess comicAccess;

    @Inject
    public UserContext(ComicAccess comicAccess) {
        this.comicAccess = comicAccess;
    }

    public List<Comic> getItemsOfInterest() {
        ...
    }

    public List<Comic> searchComics(String criteria) {
        return comicAccess.searchNoPriorPurchases(criteria, username);
    }

    public void signIn(String username) {
        this.username = username;
    }
}

Now ComicSearch is a lot simpler:

public HTML searchForComics(String criteria, String username) {
    user.signIn(username);

    List<Comic> suggestions = user.getItemsOfInterest();

    List<Comic> results = user.searchComics(criteria);
    ...
}

The real saving comes with request scoping. We already need to bind ComicSearch and UserContext in the request scope (because their state is tied to a single user's request). Now let's say that instead of signing in a user in the searchForComics() method, we're able to do it at the beginning of a request before the ComicSearch page (say, in a servlet filter). This is important because it means that authentication logic is separated from business logic. Furthermore, it means code to sign in the user need be written only once and won't have to litter every page:

public class ComicSearch {
    private final UserContext user;

    @Inject
    public ComicSearch(UserContext user) {
        this.user = user;
    }

    public HTML searchForComics(String criteria) {
        List<Comic> suggestions = user.getItemsOfInterest();
        List<Comic> results = user.searchComics(criteria);

        ...
    }
}

Notice that it is much leaner now and focused on its core purpose. But where has the code for signing in a user gone? Here's one possible way it may have disappeared.

REQUEST SCOPING IN GUICE WITH GUICE-SERVLET

Listing 5.5 shows one implementation using a Java servlet filter and the guice-servlet extension library for Guice.

Example 5.5. An injector-managed servlet filter using guice-servlet (using Guice)

There are some interesting things to say about listing 5.5:

I use a Provider<UserContext> instead of directly injecting a UserContext because UserFilter is a singleton, and once a singleton is wired with any object, that object gets held onto despite its scope. This is known as scope-widening injection and is a problem that I discuss in some detail in the next chapter.

Interestingly enough, in listing 5.4 I was able to use constructor injection to get hold of the UserContext provider:

@Inject
public UserFilter(Provider<UserContext> currentUser) {
    this.currentUser = currentUser;
 }

Ordinarily, this wouldn't be possible for a filter registered in web.xml according to the Java Servlet Specification. However, guice-servlet gets around this by sitting between Java servlets and the Guice injector. Listing 5.6 shows how this is done, with a web.xml that is configured to use guice-servlet.

Example 5.6. web.xml configured with guice-servlet and Guice

Guice-servlet's architecture is depicted in figure 5.19.

Notice that in listing 5.6 a servlet context listener named MyGuiceCreator is registered. This is a simple class that you create to handle the job of bootstrapping the injector. It is where you tell guice-servlet what filters and servlets you want the Guice injector to manage. Here's what a MyGuiceCreator would look like if it were configured to filter all incoming requests with UserFilter (to do our authentication work):

public class MyGuiceCreator extends GuiceServletContextListener {

    @Override
    protected Injector getInjector() {
        return Guice.createInjector(new ServletModule() {
@Override
            protected void configureServlets() {
                filter("/*").through(UserFilter.class)

            }
        });
    }
}

Figure 5.19. Incoming requests are rerouted by guice-servlet to injector-managed filters or servlets.<br></br> 

This code is self-explanatory, but let's go through it anyway. Remember, MyGuiceCreator is a class you provide to bootstrap and configure the injector (it must extend GuiceServletContextListener). The factory method Guice.createInjector() takes instances of Guice's Module as argument. You configure filters in guice-servlet via a programmatic API (rather than web.xml):

filter("/*").through(UserFilter.class)

You could continue adding filters and servlets. Each servlet and filter must be annotated @Singleton.

Let's get back to request scoping. By moving code out to the UserContext object, every request receives its own instance of ComicSearch and UserContext. We were able to achieve this transition without any impact to ComicAccess and minimal impact to ComicSearch. Declarative scoping of objects is thus a very powerful and unintrusive technique.

This is all very well. But how do we actually bind these scopes in Spring, Guice, and others? Let's take a look:

import com.google.inject.servlet.RequestScoped;

public class ComicStoreModule extends AbstractModule {

    @Override
    protected void configure() {

    bindComicAccess.class).to(ComicAccessImpl.class).in(Singleton.class);

        bind(UserContext.class).in(RequestScoped.class);
        bind(ComicSearch.class).in(RequestScoped.class);
        ...
    }
}

In the example code, I've bound both UserContext and ComicSearch in @RequestScoped. This is a scope made available by guice-servlet and represents the HTTP request scope in the world of Guice.^[25] ComicAccess is a simple singleton, and so it is a straightforward binding (to its implementation, ComicAccessImpl):

bind(ComicAccess.class).to(ComicAccessImpl.class).in(Singleton.class);

This same effect can be achieved in Spring with its own set of web-specific scoping utilities. The following section explores the techniques involved there.

REQUEST SCOPING IN SPRING

In Spring's XML configuration mode, these bindings are slightly different (see listing 5.7).

<beans ...>
    <bean id="data.comics" class="ComicAccessImpl" scope="singleton">

...
    </bean>

    <bean id="web.user" class="UserContext" scope="request">
        <constructor-arg ref="data.comics"/>
    </bean>

    <bean id="web.comicSearch" class="ComicSearch" scope="request">
        <constructor-arg ref="data.comics"/>
        <constructor-arg ref="web.user"/>
    </bean>
</beans>

The only new thing in listing 5.7 is the attribute scope="request" on bindings web.user and web.comicSearch. Of course, none of the three classes need change at all. Like Guice and guice-servlet, Spring requires additional configuration in web.xml. First off, you need to bootstrap a Spring injector when the web application is deployed. In Guice we used a ServletContextListener (recall MyGuiceCreator, the subclass of GuiceServletContextListener). You do this in Spring too:

<web-app ...>
    ...
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/comic-store.xml</param-value>
    </context-param>

    <listener>
        <listener-class>
            org.springframework.web.context.ContextLoaderListener
        </listener-class>
    </listener>
    ...
</web-app>

This web.xml is similar to the one we saw earlier with guice-servlet. Notice that we needed to set a context parameter with the name of the XML configuration file. You can think of it as the web equivalent of the following:

Now we've bootstrapped the injector and told it where to find its configuration. But that's not all; as guice-servlet did for Guice, there's still an integration layer that needs to be configured to get request scopes going:

<web-app ...>
    ...
    <listener>
        <listener-class>
            org.springframework.web.context.request.RequestContextListener
        </listener-class>
    </listener>
    ...
</web-app>

This listener must appear in addition to the ContextLoaderListener shown previously. Now you're set up to shop comics with Spring.

Apart from these practical aspects, there are things to keep in mind about request scoping:

Most of these are pretty low-level and specific to the architecture in question. In the Java servlet world, threads and requests are almost always the same thing (though once completed, a thread may clear its context and proceed to service other requests). So you should be careful to clean up at the end of a request. If you are designing request scopes, you should carefully research these potential hazards. Perhaps even more useful than the request scope is the HTTP session scope. This technique allows you to keep objects around between requests in a semantic user session. Using dependency injection, a lot of the glue code to make this happen goes away. Session scoping is thus a powerful tool in the dependency injector's toolbox.

An HTTP session scope is the next step up from a request scope. HTTP sessions are an abstraction invented to make up for the fact that the HTTP protocol is stateless. This means that it does not easily allow for long-running interactions with a user to be maintained on the server side. To get around this, developers use clever techniques and string together a series of requests from the same user and call it a session (figure 5.20).

An HTTP session has important characteristics:

Figure 5.20. A series of related requests from the same user forms an HTTP session.<br></br> 

You can visualize a session as made up of multiple independent requests from the same user (as in figure 5.20). In figure 5.21, each instance of a request-scoped object is unique to that request (R1 to R3). But a session-scoped instance is shared across all those requests.

Sessions are extremely useful for tracking state relative to a specific user, since a session always exists around one user. These uses include:

Figure 5.21. A session is composed of independent requests from a user.<br></br> 

All these use cases involve storing state temporarily, generally to improve a user's experience through the site. Whether that is about presentation or under the covers, it's about performance. And that's essentially what sessions do. Objects scoped under a session retain their state across requests, essentially continuing from where the last request left off.

Typically, sessions start and end when a user logs in and logs out. This behavior may be customized as necessary. Some requests (for static content, for example) do not participate in a user session and are considered stateless. These requests are independent of sessions, and, generally speaking, services participating in them shouldn't have any user-specific functionality.

Like requests, sessions may also be concurrent. For instance, multiple users who log in at once are said to be in different, unique sessions. While session-scoped instances are shared across requests inside a session, they are independent between sessions. Figure 5.22 shows how this might look in an injector's timeline.

In this figure, U1 is an object that exists in the first user's session, and U2 is a different instance of the same key that exists in the second user's session (it also is an aging Irish rock band). U1 and U2 are completely independent of one another. But within the first user's session, all requests share the same instance (U1)—likewise with the second user and U2. Another interesting point is that the second user's session does not start for a while into the application's life. So there is a time when U2 is out of scope while U1 is in scope, even though both are instances of the same key (let's call it U) bound under session scope.

Figure 5.22. Multiple user sessions in the life of an injector<br></br> 

Another interesting thing about figure 5.22 is that the second user actually logs out and logs back in (at the point marked re-login). This means that there are two instances of U2 for the second user because she started two sessions. The state of U2 prior to the second login is totally independent from the state after the second login. Contrast this with singleton scoping, where instance state would have been shared for the entire life of the injector, regardless of the number of sessions (or users) involved.

Let's go back to the comic store example. We had three important components:

There was also a filter that set up the UserContext each time, by extracting a username from incoming requests. Can you see any room for improvement? Let's revisit class UserContext to see if it provides any inspiration:

public class UserContext {
    private String username;

    private final ComicAccess comicAccess;

    @Inject
    public UserContext(ComicAccess comicAccess) {
        this.comicAccess = comicAccess;
    }

    public List<Comic> getItemsOfInterest() {
        ...
    }

    public List<Comic> searchComics(String criteria) {
        return comicAccess.searchNoPriorPurchases(criteria, username);

}

    public void signIn(String username) {
        this.username = username;
    }
}

Straight away there is a clear benefit from making this object session scoped. We wouldn't have to sign in the user on every request! It would be enough to do it once, at the start of the session (logical, since this would be where a user logged in) and simply let it be shared across any further requests from the same user. This would be particularly useful if the application loaded user-specific information (such as a user's full name and date of birth) on sign in, since it would save several unnecessary trips to the database on subsequent requests.

Another saving comes from the use case around caching user-specific information for quick access. If we assume that items of interest for a user are unlikely to change within a single session, there is no need to search and collate them on every request. It can be done once and stored in a memo field for further requests. Here's how you might modify getItemsOfInterest() to do just that:

By storing computed suggestions in the itemsOfInterest memo field, I save a lot of unnecessary computation so long as subsequent requests come from the same user. Each user has her own memo, in their session-scoped UserContext.

Binding UserContext to session scope is also laughably simple. As far as the injector is concerned, all you need to do is change its binding (we'll do this in Guice and guice-servlet first):

import com.google.inject.servlet.RequestScoped;
import com.google.inject.servlet.SessionScoped;

public class ComicStoreModule extends AbstractModule {

    @Override
    protected void configure() {
    bind(ComicAccess.class).to(ComicAccessImpl.class).in(Singleton.class);

        bind(UserContext.class).in(SessionScoped.class);
        bind(ComicSearch.class).in(RequestScoped.class);
        ...
    }
}

Earlier we also saw a shortcut notation, where the class was itself annotated. This is possible with session scope too, but first it requires that you to set up a scoping annotation. This must be done manually because the web scopes aren't part of the core Guice distribution. It's fairly easy to do:

public class ComicStoreModule extends AbstractModule {

    @Override
    protected void configure() {

        install(new ServletModule());

    bind(ComicAccess.class).to(CommicAccessImpl.class).in(Singleton.class);
        bind(ComicSearch.class).in(ServletScopes.REQUEST_SCOPE);
        ...
    }
}

Notice that I've removed any explicit binding of UserContext. I can now simply annotate the class, and Guice will correctly bind it to the session scope:

@SessionScoped
public class UserContext {
...
}

You could do the same with request scopes and guice-servlet's @RequestScoped annotation.

The Spring equivalent for binding UserContext under session scope is also straightforward (once you have the context listeners set up):

<beans ...>
    <bean id="data.comics" class="ComicAccessImpl" scope="singleton">
    ...
    </bean>

    <bean id="web.user" class="UserContext" scope="session">
        <constructor-arg ref="data.comics"/>
    </bean>

    <bean id="web.comicSearch" class="ComicSearch" scope="request">
        <constructor-arg ref="data.comics"/>
        <constructor-arg ref="web.user"/>
    </bean>
</beans>

No additional configuration of the web server (or servlet container) is required. Cool!

Finally, there are a couple of things to keep in mind when working with objects in the session scope: