Whats the best pattern for JSF managed beans and stateless EJBs

Question

What do you think is the best way to implement a JSF managed bean concerning session scope versus request scope? In my case I have a EAR application with a EJB module and a web module. The EJB module provides stateless session beans. In the Web module now I am using a ManagedBean in sessionScope. This bean injects some of the staeless session ejbs and holds some value objects containing business data which can be used in different pages.

@Named("workflowController")
@SessionScoped
public class WorkflowController {
    private List<ItemCollection> someList;
    private ItemCollection someBusinessData;
    /* Services */
    @EJB
    private MyService myService;

The bean provides a lot of action methods for the frontend and makes use of the stateless session bean. Is this general good practise? Or should I change my controller to request scope? I have seen projects where the frontend controller is used only in RequestScoped and injects all the business Data objects as managedProperties which are implemented as ManagedBeans in SessionScope.

In my example I have only one controller in SessionScope holding all business values and providing business methods implemented in stateless ejbs. In the other case one controller is used in RequestScopde and there are a lot of BusinessValue objects implemented as MangedBeans in SessionScope which are injected into the controller bean.

My question is: Is it bad practice to inject Session EJBs into a SessionScope Managed bean in general?

some people seem to be quick with the minus/close hand without providing an explanation...a valid question IMO — kostja

Arjan Tijms Arjan Tijms · Accepted Answer · 2012-09-07T22:26:03

If a session scoped managed bean needs to access business logic, then it's not a bad practice to inject a stateless EJB into it.

What might be a bad practice is overusing session scoped beans.

Use a session scoped beans only for things that are truly global for an HTTP session, like details about the currently logged-in user or a shopping cart. Be aware of the fact that session scoped beans might be subject to race conditions whenever the user opens multiple windows or tabs in a browser.

In a typical web applications with tens to hundreds of pages there should often only be a handful of session scoped beans at most.

For managed beans that back a single page (called a backing bean), the view scope is very often the most appropriate scope in JSF. Depending on what the page exactly does the request scope might also be appropriate. As a rule of thumb, when data is loaded when the page is initially requested that's also needed after a post-back, use the view scope. If there is no such data, try if you can get away with the request scope.

If you need to span multiple pages in a kind of flow, you could opt for passing data via GET parameters if it concerns data that is already persisted and for which you can pass Ids of them around. Otherwise you might wanna look into the conversation scope.

Unfortunately JSF 2.1 and before don't natively support the view scope for CDI managed beans, but third party projects like CODI provide an implementation (JSF 2.2 will most likely support the view scope for CDI out of the box).

Whats the best pattern for JSF managed beans and stateless EJBs

1 Answers