I'm interested What is the proper way to use JSF pages with AJAX when I use CDI.
I tested to configure the CDI beans with #SessionScoped but I found that there is a problem with AJAX.
Is it proper to use AJAX with CDI beans configured with #ConversationScoped?
And I found that I have to put conversation.begin(); into the Bean constructor and conversation.end(); into Java method which must be when the session is completed. Can I somehow do this automatically?
P.S Can I use this code to automatically free the resource when the user closes the page?
#Remove
public void finishIt(){
conversation.end();
}
And I found that I have to put conversation.begin(); into the Bean constructor and conversation.end(); into Java method which must be when the session is completed.
That's correct. See also among others How to replace #ManagedBean / #ViewScope by CDI in JSF 2.0/2.1 for a concrete code example.
Can I somehow do this automatically?
If you want a bean which must live as long as you're postbacking on a single view, then upgrade to at least JSF 2.2. It provides a CDI compatible #ViewScoped out the box.
If you however want a bean which must live as long as you reference it in a view, regardless of the view you're sitting in, then consider using #ViewAccessScoped of DeltaSpike instead. Once you navigate to a view which doesn't reference the bean anywhere, it will be trashed.
See also:
How to choose the right bean scope?
By default the Conversation object is in transient state. Invocation of the begin method marks it as long-running (when a real conversation starts). Ending conversation (by invoking end method) marks Conversation object as transient.
A transient conversation scoped bean will live for a life cycle of single request .
long-ending conversation(initiated by conversation.begin) will run unless conversation.end is called.
My question is related to this one (and probably others):
#PreDestroy never called on #ViewScoped
As stated there, there's no trivial solution to either have view-scoped beans destroyed upon navigation and the same seems to hold true for when the session expires.
What would a non-trivial approach to release (calling the #PreDestroy method) JSF view-scoped beans look like, or more specifically as soon as the session expires?
I'm using Java EE 6 and Mojarra 2.1.x on GlassFish 3.1.2.
Create a #SessionScoped bean to hold the resources (in some collection/array?) and inject it in the #ViewScoped bean and then rely on the #PreDestroy of the session scoped bean.
True, this way the resources live a little longer than you want, but that's the most easy and reliable solution you can get. If you want to keep the #PreDestroy in the view scoped bean, then you'd need to somehow make sure that the enduser always performs navigation by a HTTP POST request on exactly this view scoped bean. You can't reliably guarantee that (the enduser's PC might crash and so on).
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.
when to use Serializable backing bean in JSF?
is there any factors to go for serialization like View Scope, Session Scope, Application Scope or is anything else which requires bean to be serialized.
I'd say that session-scoped beans are eligible for serialization, because the the servlet container tries to serialize everything in the session in case it (the container) is restarted.