Web Beans provides a built-in Web Bean for controlling the lifecyle of conversations in a JSF application. This Web Bean may be obtained by injection:

@Current Conversation conversation;

To promote the conversation associated with the current request to a long-running conversation, call the begin() method from application code. To schedule the current long-running conversation context for destruction at the end of the current request, call end().

In the following example, a conversation-scoped Web Bean controls the conversation with which it is associated:

@ConversationScoped @Stateful
public class OrderBuilder {

    private Order order;
    private @Current Conversation conversation;
    private @PersistenceContext(type=EXTENDED) EntityManager em;
    
    @Produces public Order getOrder() {
        return order;
    }

    public Order createOrder() {
        order = new Order();
        conversation.begin();
        return order;
    }
    
    public void addLineItem(Product product, int quantity) {
        order.add( new LineItem(product, quantity) );
    }

    public void saveOrder(Order order) {
        em.persist(order);
        conversation.end();
    }
    
    @Remove
    public void destroy() {}
    
}

This Web Bean is able to control its own lifecycle through use of the Conversation API. But some other Web Beans have a lifecycle which depends completely upon another object.

The conversation context automatically propagates with any JSF faces request (JSF form submission). It does not automatically propagate with non-faces requests, for example, navigation via a link.

We can force the conversation to propagate with a non-faces request by including the unique identifier of the conversation as a request parameter. The Web Beans specification reserves the request parameter named cid for this use. The unique identifier of the conversation may be obtained from the Conversation object, which has the Web Beans name conversation.

Therefore, the following link propagates the conversation:

<a href="/addProduct.jsp?cid=#{conversation.id}">Add Product</a>

The Web Bean manager is also required to propagate conversations across any redirect, even if the conversation is not marked long-running. This makes it very easy to implement the common POST-then-redirect pattern, without resort to fragile constructs such as a "flash" object. In this case, the Web Bean manager automatically adds a request parameter to the redirect URL.

The Web Bean manager is permitted to destroy a conversation and all state held in its context at any time in order to preserve resources. A Web Bean manager implementation will normally do this on the basis of some kind of timeout—though this is not required by the Web Beans specification. The timeout is the period of inactivity before the conversation is destroyed.

The Conversation object provides a method to set the timeout. This is a hint to the Web Bean manager, which is free to ignore the setting.

conversation.setTimeout(timeoutInMillis);

The built-in @New binding annotation allows implicit definition of a dependent Web Bean at an injection point. Suppose we declare the following injected field:

@New Calculator calculator;

Then a Web Bean with scope @Dependent, binding type @New, API type Calculator, implementation class Calculator and deployment type @Standard is implicitly defined.

This is true even if Calculator is already declared with a different scope type, for example:

@ConversationScoped
public class Calculator { ... }

So the following injected attributes each get a different instance of Calculator:

public class PaymentCalc {

    @Current Calculator calculator;
    @New Calculator newCalculator;

}

The calculator field has a conversation-scoped instance of Calculator injected. The newCalculator field has a new instance of Calculator injected, with a lifecycle that is bound to the owning PaymentCalc.

This feature is particularly useful with producer methods, as we'll see in the next chapter.