I am experimenting with Jakarta EE and Jakarta Faces (JSF).
I just made a CDI named session scoped bean (as JSF managedBean's are deprecated now),
and was wondering why one would use a stateful EJB when scoped beans (running in the CDI container) are available, it seems to me that any transactions can be done using a stateless bean injected into the CDI managed bean.
Any real-world use cases would be really helpful :).
For those wondering, my Managed/named bean looks like this:
import jakarta.ejb.EJB;
import jakarta.enterprise.context.SessionScoped;
import jakarta.inject.Named;
#Named("userBean")
#SessionScoped
public class UserSessionBean implements java.io.Serializable{
#EJB
TransactionBean bean; //can be used to persist user data
String username;
String password;
// Constructor, getters and setters
}
why one would use a stateful EJB when scoped beans (running in the CDI
container) are available
Practically speaking almost never. Stateful Enterprise Beans were never intended as (scoped) backing beans anyway, and even when EJB was still recommended to be used, the stateful variation had little usage in web applications.
Originally the stateful enterprise bean had more utility when using it as a remote component using CORBA/RMI (e.g., as a kind of binary Servlet).
There's a highly specialised and somewhat obscure use-case for them now when taking advantage of the extended persistence context in Jakarta Persistence (JPA). Somehow in over a decade we never managed to specify its behaviour for other beans than stateful session beans.
Is is possible to inject JSF Managed Bean into an EJB? I have injected JSF Managed Beans in to another JSF Managed Bean as a #ManagedProperty. But when I do the same to the EJB, I get a null point exception.
No, that's not possible. The #ManagedProperty works inside #ManagedBean classes (JSF managed beans) only. You can only use #EJB or #Inject to inject another EJB or a CDI managed bean (a #Named class).
However, it makes design technically no sense to inject a front-end class like a JSF or CDI managed bean in a business service class like an EJB. An EJB should be designed in such way that it can without changes be reused together a completely different front-end like JAX-RS webservice or even a plain vanilla servlet. An EJB should absolutely not have any javax.faces.* imports/dependencies (like as that it should not have any javax.ws.rs.* nor javax.servlet.* ones).
If you intend to pass data from the JSF managed bean to an EJB, then just pass it as method argument. Such data is usually in flavor of a JPA #Entity or at least an ID/keyword which returns an entity.
Is this a correct approach to inject #ApplicationScoped bean in #SessionScoped bean? will this lead my application scoped bean to be stored in the session of every user?
I have an application scoped bean that contains some values we share among all the system users, and now I need to get that values within a method in a session bean.
Injecting a bean of the same or a broader scope in another bean is completely legal and correct either in JSF or CDI beans, like the example you provided.
The difference between CDI beans and JSF managed beans regarding that is when you try to inject a bean of a narrower scope in another bean (e.g inject #RequestScoped bean into #SessionScoped one), which is only possible as long as you are using CDI #Named beans, while not possible when working with JSF #ManagedBean.
The reason why this is possible for CDI beans is related to their Proxy Pattern mechanism, which is more flexible compared with the JSF mechanism (based on invoking the setters in order to directly inject a physical instance).
This proxy mechanism, allow the CDI container to pass a reference to a proxy instead of the injected bean (unless a bean has the default scope #Dependent). Therfore, that proxy will be responsbale of handling all calls to the injected bean and forward / redirect them to the correct bean instance.
See also:
CDI: Contexts and Dependency Injection for the Java EE platform - Client proxies
Java EE 6 #javax.annotation.ManagedBean vs. #javax.inject.Named vs. #javax.faces.ManagedBean
Backing beans (#ManagedBean) or CDI Beans (#Named)?
ManagedProperty in CDI #Named bean returns null
All of my JSF 2.0 Managed Beans are Request Scoped. Do I need to bother to make them Serializable?
It is not necessary on RequestScoped beans. On the contrary, if your beans are SessionScoped you need to make them Serializable.
No, but for the 0.001% chance the system will give them the same id it's best to make them Serializable.
If your bean is in request scope there's no need to serialize your bean..
However if your bean is viewScoped there is every need to serialize your bean...
I came across the terms "managed bean" and "backing bean" in several forums. Many people think both are the same. But, there seems to be a slight difference. Can any one help me to understand the exact difference between these two terms?
Changing my initial answer - there is no meaningful difference between the two. The tutorial says that backing beans are later declared as managed beans. So, to summarize:
a backing bean is the class out of context
a managed bean is the backing bean whenever it is declared to be used with the JSF managed bean facility.
I've never actually used the term "backing bean", because I found no use to it. So you might be better off using only "managed bean". Note that in JSF 2.0 (and in CDI) you have #ManagedBean- so your bean is a managed bean.
BalusC suggested that "backing bean" is the definition, and "managed bean" is the instance. While this might have been the original idea of JSF creators, I don't think it is worth supporting it. CDI and spring for example don't have different term for "bean definition" and "bean instance".
The JSF 2.0 specification mentions the term "backing bean" only a few times, with no definition whatsoever. In addition to that it mentions "backing bean class", which might mean that "backing bean" != "backing bean class", which brings further confusion.
So to conclude - for me both are interchangeable, and I'd stick to only using "managed bean"
What is Managed Bean?
JavaBean objects managed by a JSF implementation are called managed beans.
A managed bean describes how a bean is created and managed.
It has nothing to do with the bean's functionalities.
What is Backing Bean?
Backing beans are JavaBeans components associated with UI components used in a page.
Backing-bean management separates the definition of UI component objects from objects that perform application-specific processing and hold data.
The backing bean defines properties and handling-logics associated with the UI components used on the page.
Each backing-bean property is bound to either a component instance or its value.
Backing bean also defines a set of methods that perform functions for the component, such as validating the component's data, handling events that the component fires and performing processing associated with navigation when the component activates.
What are the differences between a Backing Bean and Managed Bean?
Backing Beans are merely a convention, a subtype of JSF Managed Beans which have a very particular purpose. There is nothing special in a Backing Bean that makes it different from any other managed bean apart from its usage.
MB : Managed Bean ; BB : Backing Bean
1) BB: A backing bean is any bean that is referenced by a form.
MB: A managed bean is a backing bean that has been registered with JSF (in faces-config.xml) and it automatically created (and optionally initialized) by JSF when it is needed.
The advantage of managed beans is that the JSF framework will automatically create these beans, optionally initialize them with parameters you specify in faces-config.xml.
2) BB: Backing Beans should be defined only in the request scope
MB: The managed beans that are created by JSF can be stored within the request, session, or application scopes .
Backing Beans should be defined in the request scope, exist in a one-to-one relationship with a particular page and hold all of the page specific event handling code.
In a real-world scenario, several pages may need to share the same backing bean behind the scenes.
A backing bean not only contains view data, but also behavior related to that data.
Backing Bean is any bean that is bound with JSF UI. while Managed bean is any bean
Simply put,
You as developer do:
#ManagedBean(name="managedBean")
#RequestScoped
public class BackingBean {
// ...
}
JSF as bean management framework does under the covers:
BackingBean managedBean = new BackingBean();
externalContext.getRequestMap().put("managedBean", managedBean);
So, the backing bean is the concrete class which is developed by you and usually tied to the view, and the managed bean is the concrete instance, which is under the covers created and put in the desired scope by the bean management framework on demand, and available by #{managedBean} in EL. You never need to create and put it in the scope yourself. If you did so then there's no means of a framework-managed bean.
CDI #Named and Spring #Component do essentially the same thing as JSF #ManagedBean.
To learn more about how bean management frameworks like JSF, CDI and Spring find and create their managed beans, the following troubleshooter should provide in depth insight: Identifying and solving javax.el.PropertyNotFoundException: Target Unreachable.
See also:
What components are MVC in JSF MVC framework?
JSF Controller, Service and DAO
JSF managed bean naming conventions
http://docs.oracle.com/javaee/5/tutorial/doc/bnaqm.html says
A typical JavaServer Faces application includes one or more backing beans, each of which is a JavaServer Faces managed bean that is associated with the UI components used in a particular page. Managed beans are JavaBeans components (see JavaBeans Components) that you can configure using the managed bean facility, which is described in Configuring Beans. This section introduces the basic concepts on creating, configuring, and using backing beans in an application.
http://docs.oracle.com/javaee/6/tutorial/doc/bnaqm.html makes no mention of "backing bean".
Managed Beans are managed (instantiated and destroyed) by container.
Backing Beans are managed beans that back views as data models.
I would say that the backing bean is a bean used strictly for UI purposes, that is, referenced in the jsp files. After all, all beans managed by JSF container are managed beans, however there are different contexts in which they might be used. For more see accepted answer here: JSF : ManagedBean, Good place to deal with Business Logic?
Backing Bean is a kind of Managed Bean. Managed Bean is an Object (i.e. instance of a Class ), created by a container (that's why it is called managed) and of course that Object has a Class and if you feel like it, you can create as many instances of that class no matter what annotation they have with m = new MyManagedBean(), just it will be a Not-So-Managed-Bean or at least not managed by a container but managed by you :)
And backing bean is a kind of managed bean (as Santosh put it: a convention) that usually uses the JSF requestScope (but in some frameworks like ADF there is even a designated scope only for backing beans called backingBeanScope - you would have never guessed) .
And yes... The flavor of jsf managed beans that one would call BackingBeans is used to bind UIComponents and write ActionListeners, while lets say "model beans" flavor would go in the session scope for example and hold your data
I took a very good (expensive) course on JSF. What I learned there is just about what is explained in http://www.avromroyfaderman.com/2008/07/from-backing-bean-to-managed-bean/.
Perhaps this difference is not the theoretical difference or the etymology of the terms, but it is certainly a very practical way to set up your architecture, especially if you are part of a large project with multiple developers and/or need to maintain a lot of code for a long time. Basically the idea is that you put your UI Business Logic in Managed Beans. Backing beans are sparse and just support the page itself.
From this link JSF - Managed Beans
Managed Bean :
Managed Bean is a regular Java Bean class registered with JSF. In other words, Managed Beans is a java bean managed by JSF framework.
From this link Creating and Using a Backing Bean for a Web Page :
Backing Bean :
In JSF, backing beans are JavaBeans used mainly to provide UI logic and to manage data between the web tier and the business tier of the application (similar to a data transfer object). Typically you have one backing bean per JSF page. The backing bean contains the logic and properties for the UI components used on the page.
NB:
For a backing bean to be available when the application starts, you
register it as a managed bean with a name and scope
Managed Bean:
A managed bean is a backing bean that has been registered with JSF (in faces-config.xml) or using Annotations. Managed Bean automatically created (and optionally initialized) by JSF when it is needed.
If you use Managed Bean in your application you have to use following syntax in JSF page to set or get values form bean
<h:inputText value="#{user.name}"/>
Backing Bean:
A bean that contains some or all component objects of a web form. Such a bean is called a backing bean for the web form.
When you use a backing bean, you need to wire up the components on the
form to those on the bean. You use the binding attribute for this purpose
Example:
<h:inputText binding="#{myForm.myComponent}" .../>
Observe how we are getting or setting values to Backing bean.
Backing Beans should be defined in the request scope, exist in a one-to-one relationship with a particular page and hold all of the page specific event handling code
Hope it useful to someone.