RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


How Java EE 6 Scopes Affect User Interactions

Java EE 6 supports a suite of five scopes, each with its own behavior for managing the user's interaction with a Java Web application. Find out how and when to use them.


As you probably know, scopes are a very important aspect of a Web application. The scope notion represents the idea that an object belongs to a certain part of an application. So, you can use scopes for holding state over the duration of the user's interaction with the application. In Java Web applications, request and session scopes are the most commonly used but the Java EE 6 specification supports a suite of five scopes, any of which can accept an object.

In this article, I will present each of the Java EE 6 scopes in the context of a Java Bean and I will demonstrate its behavior through a simple JSF/XHTML page.

Java EE 6 Scopes Overview

The Java EE 6 scopes are summarized in the table below, which presents the scope annotation, scope class and a short description for each one. I will detail each of them in the sections to follow.


Scope Class

Scope Annotation

Short Description




Default scope




Single HTTP request/user




Multiple HTTP requests/user




A short-lived/controlled session




All users share the same state

Java EE 6 Request Scope

The request scope is very useful in any Web application, and an object defined in the request scope usually has a short lifespan. When the container accepts an HTTP request from the client, the specified object is attached to the request scope and it is released when the container has finished transmitting the response to that request. A new HTTP request always comes in a new request scope object. In short, a request scope represents a user's interaction with a Web application in a single HTTP request.

In Java EE 6, you place a Java Bean under the request scope by annotating the Bean with @RequestScoped and importing the javax.enterprise.context.RequestScoped class. For example, this Bean generates random numbers and stores them in an ArrayList:

package rnd.beans;

import java.util.ArrayList;
import java.util.Random;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;

@Named(value = "rndBeanRequest")
public class rndBeanRequest {

    private ArrayList rnds = new ArrayList();
    private int rnd = 0;

    /** Creates a new instance of rndBeanRequest */
    public rndBeanRequest() {

    public int getRnd() {
        return rnd;

    public void setRnd(int rnd) {
        this.rnd = rnd;

    public ArrayList getRnds() {
        return rnds;

    public void setRnds(ArrayList rnds) {
        this.rnds = rnds;

    public void newRnd() {
        this.rnd = new Random().nextInt(100);

Note: The @Named annotation is used by Java EE 6 applications to make the Bean accessible via EL (EL stands for Expression Language, used by JSPs and JSF components).

For example, you can build a simple test for the above Java Bean using JavaServer Faces (JSF):

Just generated:
<h:outputText value="#{rndBeanRequest.rnd}"/>

List of generated numbers: <h:dataTable var="t" value="#{rndBeanRequest.rnds}"> <h:column> <h:outputText value="#{t}"/> </h:column> </h:dataTable> <h:form> <h:commandButton value="Get Random" actionListener="#{rndBeanRequest.newRnd}" action="index.xhtml"/> </h:form>

You can see the effect of the request scope very easily:

  1. Each time you press the Get Random button, a new number is generated.
  2. Most importantly, you can't keep a list of generated numbers because for every request a new Bean instance is created and a new empty list is created and filled with only the last random number generated. This makes the list useless.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date