Create SessionScoped version of ApplicationScoped bean - jsf

I have an #ApplicationScoped bean which I create a bunch of instances of. I then use those instances to create a JSF page with the data contained in the instances. I want the user to be able to modify those data (for thier use only, not stored), but not have it affect the view for other users who share access to the same bean. I'm considering creating a #SessionScoped version of the #ApplicationScoped bean for each new session, but am not sure what the best way to go about it is. Should I:
Extend the #ApplicationScoped bean and give it #SessionScoped, then in my constructor, grab all of the relvant data?
Not create a #SessionScoped version, but rather create a "user" version for each piece of data that the user can modify in the #ApplicationScoped bean?
Other ideas?

I have an #ApplicationScoped bean which I create a bunch of instances
of.
That's wrong , the real purpose of an #ApplicationScoped bean is to minimize data redundancy in the JVM's Heap memory. There should be only one instance at any time, that one instance is always accessible by any other scoped beans. As suggested by Luiggi Mendoza above, you can go for a #SessionScoped or #ViewScoped bean, depending on your use case.
But simply, never use an #ApplicationScoped bean if the data is not going to be shared or persisted.

I really recommend you to read this other question to improve your architecture design: Understanding JSF as a MVC framework
It seems you have started to code in the wrong sense. During design-phase of development, you should first think about #sessionscoped beans that your application will need (something as thinking in your users-needs). Then, you should thing about the #applicationscoped beans (like your global-application-needs).
It is really strange to build a #sessionscoped bean extending it from an #applicationscoped bean.
You should write a #sessionscoped with all the necessary data and initialize it with relevant data, as you said. You will still be able to access #applicationscoped method's. Anyway, try to minimize your access to #apllicationscoped beans, code into #sessionscoped bean as much as possible.
Regards,

Related

Getting data from JSF controller to EJB [duplicate]

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.

Using both #Stateful and #SessionScoped for shopping cart EJB

I know there's a lot of debate on using stateful vs stateless EJBs in web applications.
The shopping cart is the most common use case: Oracle's Java EE examples use it a lot in the official docs, too.
Here on stackoverflow I found many interesting answers like this The Shopping Cart dilemma in JavaEE which often say something like:
ok... SFSB are good in enterprise, complex scenarios, e.g. if you want to share them with other applications and make them available not only to JSF/web clients
but... if you're just developing your grandpa's e-commerce website, just stick to the HttpSession / SessionScoped cdi-managed bean, and write your business methods in SLSB, as they are more efficient, and so on...
However, because I'm still in a learning and discovery phase, I just want to give SFSB a try, by myself, trying to build a simple shopping cart.
I saw an interesting tutorial suggesting to store a JNDI-retrieved instance of the #Stateful shopping cart ejb interface in the HttpSession, the first time the web client needed it, then use it as usual, during the web session. In my JSF presentation layer, I suppose I would have a #SessionScoped #Named bean (let's call it ShopController), and, in its initialization, store one instance of the stateful ejb in an instance variable.
I wonder if it's possible to directly bind the #Stateful bean to the http session by annotating it with the #SessionScoped CDI annotation.
Will it work as described above? Will CDI create one SFSB for each web session?
#SessionScoped is for #Named beans and #Stateful is for #EJB beans. If I'm not wrong, you cannot annotate 1 bean with both. If you want to use #Stateful, just annotate your ShoppingCart bean with #EJB and #Local and then reference it in your ShopController. Something like this:
#Named
#SessionScoped
public class ShopController {
...
#EJB
private ShoppingCart cart;
...
// Getters and Setters
}
#Local
#Stateful
public class ShoppingCart {
...
}
Don't waste your time learning how to use SFSB for web applications. You will have scalability issues very soon. Why would you learn how to make an application that uses unnecessary server resources?
Even your managed beans shouldn't be SessionScoped. At most create only one very thin SessionScoped MB with small user data to track it and all others should be request, view scoped.
The answer to your question is yes, you can use CDI to bind SessionScoped MB to SFSB EJBs. But this is not a nice architecture for web applications.

Injecting JSF Managed Bean to a EJB

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.

JSF 2.0 - ViewScope and SessionScope advantages?

It would be great if someone can help me understand, what's the advantage of ViewScoped bean when we have SessionBean injected into it.
Can we still save on session memory usage?
If we use only SessionScoped bean or ViewScoped bean with injected SessionBean, I believe there is no difference in session memory footprint.
Why do we go through so much hassles of using View and Session scoped beans when everything is achieved so smoothly with SessionScoped beans.
Thanks,
Sundeep
It's a very common situation when you need to keep the data just for one page and then destroy it when you navigate to another page. That makes #ViewScoped bean a reasonable choice. #SessionScoped managed bean will keep all the data in session. So, why pollute your session map, when the data is no longer needed?
Also note, that the #ViewScoped annotation is not available in CDI. So if you're using beans with #Named annotation (rather than #ManagedBean), then you're out of luck. However, there are some alternatives.
When you place everything in your session you are using more memory. The session usally expires after 35 minutes or your default.
Viewscoped beans are free for garbage collection after you switched the views.
For smaller objects it probably doesn't matter much in smaller applications. However if you for example store the return values from a database in your session you will have to care about the used up memory.

Difference between managed bean and backing 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.

Resources