@ApplicationScoped

An application-scoped managed bean instance is tied to the lifetime of the web application itself. It’s under the hood represented as an attribute of the ServletContext which is created on the web application’s deployment and destroyed on the web application’s undeployment. Note that this is not equal to the server’s startup and shutdown. Web applications can be deployed and undeployed on a running server.

In other words, there’s only one instance of an application-scoped managed bean throughout the web application’s lifetime which is shared across all requests and sessions. You could argue that it behaves like a singleton. However, it doesn’t actually follow the singleton design pattern. It follows the “just create one” design pattern.⁵ A real singleton doesn’t have any public constructor but only a static method which returns a statically initialized lazy loaded instance. A real JavaBean, on the other hand, requires the presence of a default constructor.

By default, an application-scoped bean managed instance is created for the first time when the web application’s code accesses it for the first time during the web application’s lifetime. It’s thus not, per definition, immediately created when the ServletContext instance is created. It is, however, guaranteed when the ServletContext instance is destroyed.

Application-scoped managed beans are useful for application-wide data which needs to be initialized only once in the application’s lifetime, or needs to provide non-static getters which delegate to static variables, or needs to provide functions for usage in EL. The following example makes sure that application settings stored in the database are loaded only once and provided as a Map by #{settings} during the rest of the application’s lifetime .

@ApplicationScoped
public class ApplicationSettingsProducer {

    private Map<String, String> settings;

    @Inject
    private ApplicationSettingsService applicationSettingsService;

    @PostConstruct
    public void init() {
        settings = applicationSettingsService.getAll();
    }

    @Produces @Named
    public Map<String, String> getSettings() {
        return settings;
    }
}

Note that the @Named annotation is placed on the getter, which implies a managed bean name matching the property name: #{settings}. Also note that the getter in turn needs the @Produces annotation in order to be recognized as a managed bean producer. Following is another example which offers text formatting functions .

@Named @ApplicationScoped
public class Format {

    public String date(LocalDate localDate) {
        if (localDate != null) {
            return localDate.format(DateTimeFormatter.ISO_LOCAL_DATE);
        }
        else {
            return "n/a";
        }
    }

    public String currency(BigDecimal amount) {
        if (amount != null) {
            return NumberFormat.getCurrencyInstance(Locale.US)
                .format(amount);
        }
        else {
            return "n/a";
        }
    }
}

This could be useful in, for example, a data table to keep the Facelets code terse.

<h:dataTable value="#{cart.products}" var="product">
    <h:column>#{format.date(product.lastModified)}</h:column>
    <h:column>#{format.currency(product.discount)}</h:column>
</h:dataTable>

It’s also useful in case you need a formatted value in an attribute which doesn’t allow a nested <h:outputText><f:convertXxx>.

<h:commandLink ... title="Last visited #{format.date(user.lastVisited)}">

@SessionScoped

A session-scoped managed bean instance is tied to the lifetime of the established HTTP session. It’s under the hood represented as an attribute of the HttpSession which is created for every unique client on demand of the web application’s code. When the web application’s code directly or indirectly pokes the HttpSession for the first time via HttpServletRequest#getSession(),the servlet container will create a new HttpSession instance, generate a long and unique ID, and store it in server’s memory. The servlet container will also set a session cookie on the HTTP response with “JSESSIONID” as the cookie name and the unique session ID as the cookie value. A “session cookie” is identified by the absence of the “maximum age” attribute.

As per the HTTP cookie specification, the client (the web browser) is required to send this cookie back in the header of the subsequent requests as long as the cookie is valid. In any decent web browser you can inspect the request and response headers in the “Network” section of the web developer’s toolset which is accessible by pressing F12 in the web browser. The servlet container will check every incoming HTTP request for the presence of the cookie with the name “JSESSIONID” and use its value (the session ID) to get the associated HttpSession instance from server’s memory.

On the server side, the HttpSession instance stays alive until it has not been accessed for more than the timeout value as specified in the <session-timeout> setting of web.xml, which defaults to 30 minutes on most if not all servlet containers. So, when the client doesn’t visit the web application for longer than the time specified, the servlet container will destroy the HttpSession instance. Every subsequent HTTP request, even with the cookie specified, will not have access to the HttpSession instance anymore; the servlet container will create a new HttpSession instance and overwrite the cookie value with the new session ID.

On the client side, by default, all session cookies stay alive for as long as the browser instance is running. So, when the client shut downs the browser instance, all session cookies are destroyed on the client side. In a new browser instance, the session cookies from a previous browser session are not available any more, so the browser won’t send any JSESSIONID cookie. The server will then interpret it as a brand-new session. The HttpSession instance associated with the previous browser session will silently expire on the server side.

By default, a session-scoped managed bean instance is created for the first time when the web application’s code accesses it for the first time during the HTTP session’s lifetime. It’s thus not, per definition, immediately created when the HttpSession instance is created. It is, however, guaranteed to be destroyed when the HttpSession instance is destroyed. Session-scoped managed beans are effectively shared across all browser tabs within the same browser session .

Session-scoped managed beans are useful for keeping track of client-specific data, such as the entity representing the currently logged-in user, the selected language, and other user-related preferences. The following example calculates the current locale and provides a getter/setter for it so that it can be obtained in the view and modified by an UIInput component.

@Named @SessionScoped
public class ActiveLocale implements Serializable {

    private Locale current;

    @PostConstruct
    public void init() {
        FacesContext context = FacesContext.getCurrentInstance();
        current = context.getApplication()
            .getViewHandler().calculateLocale(context);
    }

    // Getter+setter.
}

A more elaborate example can be found in the section “Changing the Active Locale” in Chapter 14. Do note that session-scoped managed beans must implement Serializable because the HttpSession instance itself, where those beans are being stored, is subject to being written to disk in case of a server restart or even to being transferred over the network to a different server in case of a server cluster configuration with a distributable session .

Another classic example is a “shopping cart.”

@Named @SessionScoped
public class Cart implements Serializable {

    private List<Product> products = new ArrayList<>();

    public void addProduct(Product product) {
        products.add(product);
    }

    // ...
}

@ConversationScoped

A conversation-scoped managed bean is tied to the lifetime of the injected javax.enterprise.context.Conversation instance which offers begin() and end() methods which must be explicitly invoked by the web application’s code in order to indicate the start and end of the conversation scope. The conversation scope is represented by a predefined HTTP request parameter with a default name of “cid” (“Conversation ID”) whose value references represents the conversation ID. The conversation ID in turn references an isolated mapping in the current HTTP session where the conversation-scoped managed bean instances will be stored.

As long as the conversation scope has not started, the conversation-scoped managed bean will behave like a request-scoped managed bean. When the application code explicitly invokes Conversation#begin(), then the conversation scope will start and a custom javax.faces.application.ViewHandler provided by the CDI implementation will make sure that all its getXxxURL() methods such as getActionURL() and getBookmarkableURL() return a URL (uniform resource locator) with the conversation ID parameter included. In case of Weld, that’s the ConversationAwareViewHandler.⁶ All JSF UIForm and UIOutcomeTarget components derive their action and target URLs from those methods of the ViewHandler. The generated HTML output of those components will thus ultimately include the conversation ID in the target URL.

On an incoming HTTP request, when the conversation ID parameter is present in the request, and it is still valid, the CDI implementation will obtain the associated conversation scope from the HTTP session and make sure that all conversation-scoped managed beans are obtained from exactly this conversation scope identified by the conversation ID. This works on both GET and POST requests. Any form submit or any link/navigation to a URL with the conversation ID included will provide access to the very same conversation scope, as long as it’s still valid. The conversation scope ends when the application code explicitly invokes Conversation#end(). When the end user reuses the “cid” request parameter later, or manipulates its value to one which isn’t started in its own browser session, or when the underlying HttpSession instance is destroyed, then CDI will throw a javax.enterprise.context.NonexistentConversationException.

Conversation-scoped managed beans are particularly useful in order to be able to return to a particular stateful page within the same browser session after being redirected elsewhere. A classic example is a third-party web service which is included in an HTML <iframe> or opened in a new browser tab or even targeted in the action attribute of a plain HTML <form>, and can, via a specific request parameter, be configured to redirect back to your web application after completing the service. When you include the conversation ID in the redirect URL, then you will in the redirected page be able to resume with exactly the same conversation-scoped managed bean instance as it was before the redirect. This allows you the opportunity to finalize and unlock any pending transactions and, of course, end the conversation .

Given a checkout button which looks as follows,

<h:form>
    ...
    <ui:fragment rendered="#{empty payment.url}">
        ...
        <h:commandButton value="Checkout" action="#{payment.checkout}">
            <f:ajax render="@form" />
        </h:commandButton>
    </ui:fragment>
    <ui:fragment rendered="#{not empty payment.url}">
        <iframe src="#{payment.url}"></iframe>
    </ui:fragment>
</h:form>

here’s what the associated conversation-scoped bean behind #{payment} looks like:

@Named @ConversationScoped
public class Payment implements Serializable {

    private Order order;
    private String url;

    @Inject
    private Cart cart;

    @Inject
    private OrderService orderService;

    @Inject
    private Conversation conversation;

    public void checkout() {
        conversation.begin();
        order = orderService.lockProductsAndPrepareOrder(cart);
        url = "http://third.party.com/pay?returnurl="
            + URLEncoder.encode("http://my.site.com/paid?cid="
            + conversation.getId(), "UTF-8");
    }

    public void confirm() {                                                                                      
        orderService.saveOrderAndCreateInvoice(order);
        conversation.end();
    }

    @PreDestroy
    public void destroy() {
        orderService.unlockProductsIfNecessary(order);
    }

    public String getUrl() {
        return url;
    }
}

Basically, the checkout button is only rendered when there’s no payment URL set. Once the button is pressed, all products of the shopping cart are locked and the order is prepared. Also, depending on the third-party payment service, the URL referring it must be prepared whereby you include the return URL as some query parameter in the URL of the payment service. The return URL should in turn include the “cid” request parameter representing the conversation ID. In the redirected page which will actually be loaded in the <iframe>, you can just mark the conversation complete with <f:viewAction>.

<f:metadata>
    <f:viewAction action="#{payment.confirm}" />
</f:metadata>

Of course, the average third-party payment service should have a more elaborate Java or even JavaScript API instead of <iframe>; also, it should be possible to provide different return pages for each payment outcome such as payment failed and payment aborted. The above example is just to give the general idea.

@FlowScoped

A flow-scoped managed bean is tied to the lifetime of a JSF flow. It uses the same principle as conversation scope, only the conversation is further narrowed down to a specific set of JSF views in an isolated subfolder. Once the end user clicks a JSF link or button component which navigates to a specific entry page of a JSF flow, then the flow scope will automatically start. The flow scope cannot be started when you open the entry page without navigating via a JSF component. That is, JSF will, with help of the ViewHandler, automatically append the predefined HTTP request parameter “jfwid” (“javax.faces Window ID”) to the outcome URL whose value represents the JSF client window ID. The JSF client window ID in turn references an isolated mapping in the current HTTP session where the flow-scoped managed beans are stored.

Additionally, particularly when using a UIOutcomeTarget component instead of a UICommand component to navigate, the query string may be accompanied with “jffi” (javax.faces Flow ID) and “jftfdi” (javax.faces To Flow Document ID) request parameters. Those are actually only mandatory for starting a JSF flow using a GET request. Technically, for the rest of the JSF flow, “jfwid” is sufficient. As long as the “jfwid” parameter is present, and is still valid, then the JSF flow is idempotent and can be resumed using a GET request. When you open a new browser tab and navigate into the JSF flow, then actually a new flow scope will be started, independent of the JSF flow in other tab. Once a postback request within the JSF flow navigates to a page outside the JSF flow, then the flow scope will automatically end. When the end user reuses the “jfwid” request parameter later, or manipulates its value to one which isn’t started in its own browser session, or enters the flow directly, or when the underlying HttpSession instance is destroyed, then CDI will throw a javax.enterprise.context.ContextNotActiveException.

The major difference between the flow scope and the conversation scope is thus that the pages within a JSF flow cannot be entered directly. They will automatically start when the end user navigates to the entry page of the JSF flow and they will automatically end when a postback navigates outside the JSF flow. Flow-scoped managed beans are useful in order to isolate a conversation to a specific set of JSF pages. A classic real-world example is a booking application which is spread over multiple forms in physically different pages.

There are various ways to define a JSF flow. One way is by convention, another way is by declarative configuration in the /[flowId]/[flowId]-flow.xml file, and yet another way is by programmatic configuration using javax.faces.flow.FlowBuilder API.⁷ In this book we’ll restrict ourselves to convention over configuration. First, create the following folder structure:

The first convention is that the flow entry page must have exactly the same name as the subfolder it is sitting in. In this case, that’s “booking”. This is considered the Flow ID. The second convention is that there must be a *-flow.xml file in the subfolder whose name is prefixed with the Flow ID, i.e., booking-flow.xml. This XML configuration file can be kept empty for now. It’s only useful when you want to fine-grain the JSF flow configuration , e.g., by specifying a different entry page. Without this file, the JSF flow scope won’t be activated. One disadvantage of at least one activated JSF flow in the web application, however, is that the JSF client Window ID parameter “jfwid” will be appended to every single navigation URL, even when it doesn’t target a JSF flow. This URL pollution may for some developers be the main reason to not use the JSF flow scope at all.

The navigation component in order to enter a JSF flow must be placed in a JSF page outside the flow subfolder. The navigation outcome must reference the subfolder name, which is the Flow ID. Here’s an example in /home.xhtml.

<h:button value="Start booking" outcome="booking" />

Of course, this can be substituted with <h:link>. It’s recommended to use GET just for this so that the booking page’s URL reflects in the browser’s address bar. Then, in all pages within the subfolder, you can reference a flow-scoped managed bean which will be shared across all these pages. You can navigate back and forth between these pages as well while retaining the flow-scoped managed bean instance. We recommend that you use Ajax with redirect for this. The Ajax submits will improve the user experience . The redirects will make sure that the individual pages are still bookmarkable.

/booking/booking.xhtml:

<h:form>
    <h:inputText value="#{booking.startDate}" />
    ...
    <h:commandButton value="Next" action="persons?faces-redirect=true">
       <f:ajax execute="@form" render="@form" />
    </h:commandButton>
</h:form>

/booking/persons.xhtml:

<h:form>
    <ui:repeat value="#{booking.persons}" var="person">
        <h:inputText value="#{person.name}" />
        ...
    </ui:repeat>
    ...
    <h:commandButton value="Back" action="booking?faces-redirect=true">
       <f:ajax execute="@form" render="@form" />
    </h:commandButton>
    <h:commandButton value="Next" action="confirm?faces-redirect=true">
       <f:ajax execute="@form" render="@form" />
    </h:commandButton>
</h:form>

/booking/confirm.xhtml:

<h:form>
    <h:outputText value="#{booking.startDate}" />
    ...
    <h:commandButton value="Back" action="persons?faces-redirect=true">
       <f:ajax execute="@form" render="@form" />
    </h:commandButton>
    <h:commandButton value="Next" action="payment?faces-redirect=true">
       <f:ajax execute="@form" render="@form" />
    </h:commandButton>
</h:form>

/booking/payment.xhtml:

<h:form>
    <h:selectOneMenu value="#{booking.paymentMethod}">
        ...
    </h:selectOneMenu
    ...
    <h:commandButton value="Back" action="confirm?faces-redirect=true">
       <f:ajax execute="@form" render="@form" />
    </h:commandButton>
    <h:commandButton value="Submit" actionListener="#{booking.submit()}"
       action="/home?faces-redirect=true">
       <f:ajax execute="@form" render="@form" />
    </h:commandButton>
</h:form>

And, finally, the flow-scoped bean behind #{booking}:

@Named @FlowScoped("booking")
public class Booking implements Serializable {

    private LocalDate startDate;
    private List<Person> persons;
    private PaymentMethod paymentMethod;
    // ...

    public void submit() {
        // ...
    }
}

You see, the most of navigation task is done by the action attribute of the command components.?faces-redirect=true is a special request parameter which is internally recognized by JSF as an instruction to perform a redirect after postback and of course strip off from the target URL before performing the actual redirect. Once the postback leaves the flow, the flow-scoped managed bean is destroyed and the previously presented page URLs are not reusable anymore.

@ViewScoped

A view-scoped managed bean is tied to the lifetime of the JSF view state. The JSF view state is elaborated in the section “View State” in Chapter 3. In a nutshell, a view-scoped managed bean lives as long as the end user is performing postback requests on the very same JSF view and the invoked action methods keep returning null or void. Once the action method returns non-null, even if it’s an empty string or represents the same view, then the view scope will end. View-scoped managed beans are not shared across browser tabs within the same browser session. Each one gets its own unique instance. Effectively, they are indirectly identified by the javax.faces.ViewState hidden input field in the generated HTML representation of a JSF form.

However, view-scoped managed beans are not stored in the JSF view state, not even when client-side state saving is enabled. They are actually stored in the HTTP session, regardless of the JSF state saving method. They are not immediately destroyed when the end user unloads the web page either by performing a GET request via a link or bookmark or editing the URL in browser’s address bar, or by closing the browser tab. They will stick around in the HTTP session and only get destroyed when the HTTP session expires.

As an end user can in theory spawn an unlimited amount of browser tabs within the same session, and thus also as many JSF view states and view-scoped managed beans, there’s a configurable maximum limit on the amount of JSF view states and view-scoped managed beans which will be stored in the HTTP session. Once this limit is reached, the least recently used JSF view state and view-scoped managed bean will be expired and destroyed. When the end user actually goes back to the tab that originally referenced the now expired JSF view state, and performs a postback request on it, JSF will throw a ViewExpiredException. The limit on the amount of JSF view states is dependent on the JSF implementation used. In Mojarra, this limit is configurable by the com.sun.faces.numberOfLogicalViews context parameter in web.xml whose default value is 15.⁸

<context-param>
    <param-name>com.sun.faces.numberOfLogicalViews</param-name>
    <param-value>25</param-value>
</context-param>

If your web application, however, invites being opened in many more browser tabs, such as a discussion forum or a Q&A site, then you’d better switch to client-side state saving. This way the JSF view states are no longer stored in the HTTP session and will therefore also never expire. However, the associated view-scoped managed beans are still stored in the HTTP session and expirable. When the end user actually goes back to the tab that originally referenced the now expired view scoped-managed bean, and performs a postback request on it, JSF will not throw a ViewExpiredException but instead will create a new one from scratch, thereby losing all the state changes to the original managed bean instance. The limit on the amount of view-scoped managed beans is also dependent on the JSF implementation used. In Mojarra, this limit is not yet configurable by a web.xml context parameter. It’s only configurable by explicitly setting the session attribute with the name com.sun.faces.application.view.activeViewMapsSize whose default value is 25. This can be achieved with an application-scoped managed bean as follows, which observes the initialization of the session scope.

@ApplicationScoped
public class Config {

    public void sessionCreated
        (@Observes @Initialized(SessionScoped.class) HttpSession session)
    {
        session.setAttribute
            ("com.sun.faces.application.view.activeViewMapsSize", 15);
    }
}

This configuration actually decreases the default value to be equal to default maximum amount of JSF view states in session. This is fine when you’re using server-side state saving and all your JSF views effectively reference only one view-scoped managed bean instance. However, in a decently developed and refactored JSF web application, the average JSF page usually references multiple view-scoped managed beans. If you have, for example, a maximum amount of three different view-scoped managed beans per JSF view, then you’d best set the limit to three times the value of com.sun.faces.numberOfLogicalViews. You only need to take into account the possible memory consumption. It will quickly go overboard when the view-scoped managed beans in turn hold, relatively, a lot of data.

View-scoped managed beans are very useful for retaining state across Ajax-based postbacks on the same JSF view, particularly if those postbacks result in changes in the value of the rendered attribute of any UIComponent, or the disabled or readonly attribute of an UIInput component, or the disabled attribute of any UICommand component within the same JSF view. That is, on a subsequent postback, JSF will, as part of a safeguard against a tampered request, recheck them before actually processing the component. If the managed bean holding the state was request scoped instead of view scoped, then those changes in the conditions would get lost in a subsequent postback and the postback wouldn’t get processed as intuitively expected. In other words, view-scoped managed beans are particularly useful in dynamic forms .

One example is a drop-down which conditionally renders a free text field when the “other” option is chosen.

<f:metadata>
    <f:importConstants type="com.example.project.model.Title" />
</f:metadata>
...
<h:form>
    <h:selectOneMenu value="#{bean.customer.title}">
        <f:selectItems value="#{Title}" />
        <f:ajax render="other" />
    </h:selectOneMenu>
    <h:panelGroup id="other">
        <h:inputText rendered="#{bean.customer.title eq 'OTHER'}"
            value="#{bean.customer.titleOther}" required="true" />
    </h:panelGroup>
    ...
    <h:commandButton value="Save" action="#{bean.save}" />
</h:form>

This construct won’t work when the managed bean is request scoped and is thus recreated on every request. When the drop-down changes, it creates a new instance of the request-scoped bean, sets the title there, and renders the free text field and finally the request-scoped bean instance gets destroyed. When the form submits, it creates a new instance of the request-scoped bean, thus without the customer title, and when JSF checks the rendered attribute during the apply request values phase (second phase) of the free text field and notices it’s false, ultimately it won’t process the free text field at all. It will only work when the managed bean is view scoped because the customer title set during the drop-down change is still available during the apply request values phase (second phase) of the form submit.

There is, however, a work-around. You could let the rendered attribute check the HTTP request parameter instead of the model value. As explained in Chapter 4, the HTTP request parameter name is specified by the component’s client ID. You could bind the drop-down component to the view and then use its client ID to obtain the HTTP request parameter value .

<h:selectOneMenu binding="#{title}" value="#{bean.customer.title}">
    <f:selectItems value="#{Title}" />
    <f:ajax render="other" />
</h:selectOneMenu>
<h:panelGroup id="other">
    <h:inputText rendered="#{param[title.clientId] eq 'OTHER'}"
        value="#{bean.customer.titleOther}" required="true" />
</h:panelGroup>

This way, when JSF checks the rendered attribute during the apply request values phase (second phase) of the form submit, it will notice it’s true and continue processing the free text field, even when the managed bean is request scoped and thus #{bean.customer.title} is still null at that point. Note that the binding attribute doesn’t reference a managed bean property. This is unnecessary as it wouldn’t be used over there. All of this is also applicable on the readonly attribute of any UIInput component and the disabled attribute of any UIInput and UICommand component.

There may also be cases wherein a request-scoped managed bean will work just fine but imposes a risk of a corrupted state as compared to a view-scoped managed bean, certainly when relying on data coming from a shared database which could be mutated by other users. This affects primarily use cases whereby UIInput or UICommand components are nested in an iterating component such as <h:dataTable>, <ui:repeat> and <c:forEach> which iterates over a model coming from the database. This was explained previously in Chapter 6, but for the sake of refreshment, we will explain it once more. Imagine a table of products with a delete button in a column.

<f:form id="list">
    <h:dataTable id="products" value="#{products.list}" var="product">
        ...
        <h:column>
            <h:commandButton id="delete" value="Delete"
                action="#{products.delete(product)}">
                <f:ajax render="@namingcontainer" />
            </h:commandButton>
        </h:column>
    </h:dataTable>
</h:form>

With this backing bean:

@Named @ViewScoped
public class Products implements Serializable {

    private List<Product> list;

    @Inject
    private ProductService productService;

    @PostConstruct
    public void init() {
        list = productService.list();
    }

    public void delete(Product product) {
        productService.delete(product);
        list.remove(product);
    }

    public List<Product> getList() {
        return list;
    }
}

The submitted button is under the hood identified by the iteration index. When JSF is about to process the form submit, and a product has been added or removed or even reordered in the meanwhile, causing the iteration index to be changed, then the invoked action would possibly be performed against the wrong item currently at the initially known index. This is dangerous for the integrity of the model . In such a case the value of the iteration component must refer a view-scoped model.

Also here, there is a work-around. Instead of relying on the iteration index, you can also rely on the unique identifier of the iterated object which must be passed as an HTTP request parameter instead of as an EL method argument.

<f:form id="list">
    <h:dataTable id="products" value="#{products.list}" var="product">
        ...
        <h:column>
            <h:commandButton id="delete" value="Delete"
                action="#{products.delete}">
                <f:param name="id" value="#{product.id}" />
                <f:ajax render="@namingcontainer" />
            </h:commandButton>
        </h:column>
    </h:dataTable>
</h:form>

Whereby the backing bean is adjusted as follows:

@Named @RequestScoped
public class Products {

    private List<Product> list;

    @Inject @ManagedProperty("#{param.id}")
    private Long id;

    @Inject
    private ProductService productService;

    @PostConstruct
    public void init() {
        list = productService.list();
    }

    public void delete() {
        productService.delete(id);
        list.removeIf(product -> product.getId().equals(id));
    }

    public List<Product> getList() {
        return list;
    }
}

No, the action="#{products.delete(product.id)}" instead of using <f:param> won’t work. The technical reason is that <f:param> is executed immediately during the render response phase of the form, long before the end user presses the delete button. Thus, at the moment the end user presses the delete button, it’s guaranteed to have the correct value. The EL method argument, on the contrary, is only evaluated after the end user has pressed the delete button. When the model has changed in the meanwhile, it would thus evaluate to the wrong ID when the iteration index of the particular product has changed.

As explained in the beginning of this section, the standard JSF view-scoped bean management facility has thus two major disadvantages: first, the instances don’t immediately expire when the end user unloads the web page and stick around in the HTTP session; second, even with client-side state saving enabled they are stored in the HTTP session. Those problems are currently not yet solved in the standard JSF API.

For now, the JSF utility library OmniFaces offers an enhanced @ViewScoped annotation which solves those two disadvantages.⁹ View-scoped managed beans annotated with @org.omnifaces.cdi.ViewScoped will actually get destroyed when the end user unloads the page. This is under the hood done with help of Navigator.sendBeacon API¹⁰ in JavaScript, and a specialized ViewHandler implementation provided by OmniFaces which listens on those unload requests. There have been production applications making heavy use of view-scoped managed beans whereby the memory usage has reduced for up to 80% after switching from standard JSF @ViewScoped to OmniFaces @ViewScoped. This makes the destroy-on-unload feature a major candidate to be added to the future version of the standard JSF API.

In order to save the physical view-scoped managed bean in the JSF view state when client-side state saving is enabled, the saveInViewState attribute of the OmniFaces @ViewScoped annotation must be set to true. You only need to keep in mind that those beans will never expire, not even when the page gets unloaded, or when the HTTP session expires. In fact, the entire bean has physically become part of the generated HTML output, in the javax.faces.ViewState hidden input field. There have been community requests to make JSF state management more flexible, such as toggling between client- and server-side state saving on a per-view (per UIViewRoot) or even per-form (per UIForm) basis, and being able to store view-scoped managed beans in the actual view state instead of in the HTTP session. This may also be reconsidered in a future version of the standard JSF API.

@RequestScoped

A request-scoped managed bean is among others tied to the lifetime of the HTTP request, which is for JSF the most important case. Other cases include the lifetimes of a call to an EJB asynchronous method invocation (method annotated by @Asynchronous), an EJB timer timeout method, or when a message-driven bean (MDB) processes a message. Note that an Ajax request also counts as a single HTTP request.

When the client sends an HTTP request to the server, the servlet container will create HttpServletRequest and HttpServletResponse instances representing the HTTP request and response, and pass them through the authentication modules, filters, and servlets. They will be destroyed immediately after all authentication modules, filters, and servlets are finished processing the request and response. In other words, every HTTP request creates a new instance of a request-scoped managed bean which is available only during that request and not in other requests.

Request-scoped managed beans are useful for simple and static forms which don’t have any dynamic Ajax-based updates, for which you would rather use a view-scoped managed bean. Think of a login form or a contact form.

@Named @RequestScoped
public class Login {

    private String username;
    private String password;

    // ...
}

Sure, those forms can be tied to a view-scoped managed bean as well without problems, but that’s a waste of memory space. Note that you should absolutely not make the JPA entity itself a managed bean. In other words, the following approach is factually wrong:

@Named @RequestScoped
@Entity
public class Product {
    // ...
}

Not only does this violate the Law of Demeter,¹¹ but it also risks that JPA won’t be able to persist it, because CDI actually wraps the managed bean in a proxy class and JPA would then not be able to obtain the entity information from it when you’re about to pass an injected instance to JPA. Hibernate would in such case throw “Unknown entity: com.example.Entity$Proxy$_$$_WeldClientProxy”, which thus actually represents the CDI proxy class .

You might at this point wonder how exactly CDI actually works. First, it will during the web application’s startup collect all classes that are annotated with a CDI-compatible scope annotation. Then, it will generate proxy classes for all of them. Ultimately instances of those proxy classes are being injected. Given an example bean class com.example.Bean, the generated CDI proxy class may look as follows:

public class Bean$Proxy$_$$_CDI extends Bean implements Serializable {

    public String getSomeProperty() {
        Bean actualInstance = CDI.resolveItSomehow();
        return actualInstance.getSomeProperty();
    }

    public void setSomeProperty(String someProperty) {
        Bean actualInstance = CDI.resolveItSomehow();
        actualInstance.setSomeProperty(someProperty);
    }
}

You see, it extends the bean class, makes it serializable, and uses an “impossible to clash” class name and lets all methods delegate to the actual instance obtained from the CDI context. You’ll probably also immediately understand why the CDI bean management facility requires the bean classes to be public and have a public default constructor. You’ll also see that when such a proxy class is created and injected, the underlying actual instance is not necessarily created. It’s only automatically created when the fictive CDI.resolveItSomehow() method is invoked. Under the hood, it will obtain the context from a thread local variable, exactly how FacesContext#getCurrentInstance() works.

By the way, EJB also works with serializable proxies this way. That’s why it could seemingly magically perform all the heavy lifting of starting or joining a transaction and use pooled instances. The legacy JSF @ManagedBean facility, however, did not use proxies at all. That’s exactly why it was impossible to inject a JSF managed bean of a narrower scope in a JSF managed bean of a broader scope . With CDI bean management facility this is just possible.

Note that CDI has also a @javax.enterprise.inject.Model stereotype annotation which basically bundles both @Named and @RequestScoped into a single annotation. This is in no way different from a request-scoped managed bean. Unfortunately, it does not represent a non-proxy instance; otherwise it would be nice to put it on an @Entity. The @Model annotation exists just for convenience.

@Dependent

A dependent-scoped managed bean is tied to the lifetime of the scope wherein it’s being created for the first time. So, if you inject it into an @ApplicationScoped, then it will become application scoped too. And if you inject it into a @ViewScoped, it will become view scoped too. And so on. This is the default CDI scope.

This has, however, a caveat. When you forget to declare the CDI scope annotation on your backing bean, or import a scope with exactly the same name from the wrong package, e.g., javax.faces.bean.RequestScoped instead of javax.enterprise.context.RequestScoped, and you reference it directly in EL, as in #{dependentScopedBean}, instead of referencing it via another managed bean, as in #{requestScopedBean.dependentScopedBean}, then every EL evaluation will basically create a brand-new instance which exists only within that EL context. In other words, imagine a JSF form with two input fields and a submit button, each bound to a dependent-scoped managed bean, then you will effectively end up with three separate instances. One wherein the first input field is set, one wherein the second input field is set, and one wherein the action method is invoked. So, if you ever observe odd behavior of null submitted values in the action method even though the required validation has passed, the first thing to check is the actually used CDI managed bean scope.

The major technical difference with other scopes is that dependent-scoped managed beans are not proxied. In other words, what’s being injected is the actual instance .

@Dependent
public class Entities {

    @Produces
    public Product getProduct() {
        return new Product();
    }
}

@Named @RequestScoped
public class Products {

    @Inject
    private Product product;

    @Inject
    Private ProductService productService;

    public void add() {
        productService.create(product);
    }

    public Product getProduct() {
        return product;
    }
}

Note that you still can’t use <h:inputText value="#{product.name}">, because it would get its own instance. You still need to use #{products.product.name}. For exactly this reason, the producer isn’t @Named. Also note that in case of a view-scoped managed bean, you’d need to force JSF to restart the view scope by returning a non-null outcome from action method; otherwise the injected Product instance would be reused for the next view.