I just am placing the outline of my problem here since it is very difficult to depict the real scenario. i have an application in jsf 1.2 and rich faces 3. It stores employees basic data and related data (family, employment record, qualification etc) in separate tables. when user clicks on its own name. details from several tables related to employee are shown on a page. like family, employment record, qualification record etc. primary key in employee basic table is emp_id (a number). this key is foreign key in all related child tables. Application is centrally deployed and used in different cities. the problem is, when a particular employee clicks its details....unknown records are shown in his account like family of any other employee...the interface is like
---------------------------------------------------------------------------
Wellcome Mr. Campatrick,Sales Executive <<View Details>>
---------------------------------------------------------------------------
when view details is clicked....emp_id of Mr.Campatrick is set in the employee_bean. where employee_bean is session scoped. If at all this make any sense....what could be the possible reason of mixing up of records when i categorically set the emp_id on "view details" link. It is something related to "Memory leak"? if yes, where to check it.
The problem looks to be an abuse of managed beans in session scope. Since you say you work with JSF 1.2 and RichFaces 3, I would recomend to change your managed beans from session scope to request scope and add the #KeepAlive annotation to those managed bean that must behave as view scope.
Your bean would look like
#KeepAlive
public class NoSessionScopeAnymore {
//fields, constructor, getters and setters, methods...
}
More info about the KeepAlive annotation or as component: <a4j:keepAlive>
From JSF 2 you won't need this since you can use the #ViewScoped that solves the bridge between request and session. More info about managed bean scopes:
https://stackoverflow.com/a/7031941/1065197
Communication in JSF 2 - Managed Bean Scopes
is Sessionscope put any impact on the application performance? (is tagged as JSF 2 but this applies for JSF 1.2 as well)
Related
We're making usage of Primefaces Wizard component and the forms been included within the Wizard's TABs were declared inside some UI Fragments with their respective Managed Beans. Each one of the Managed Beans contains properties representing some Entities.
What we need to achieve is that, for every completed step, we take the above mentioned Entity property that was previously fulfilled and designate the same Entity property inside the Wizard Managed Bean, and later we may present the Entities data like a summary, so the user would decide whether to proceed or not.
I'm wondering whether there are some other options to accomplish that rather than set a Session variable across the Wizard navigation.
Is the JSF #ManagedProperty usage feasible?
Tks.
in a jsf 2.2 application, there is page called test.xhtml that take a paramater called ‘id’ , for example test.xhtml?id=200 . The page is backed by a CDI Session bean named ‘TestBean’. The page has this code to load data:
<f:metadata>
<f:viewAction action="#{testBean.redirectNoParameters}"></f:viewAction>
</f:metadata>
Now based on the id, the application load a set of fields in the session bean with the right values.
public String redirectNoParameters() {
//Code…
//Load fields
test = testDao.find(id);
//Code…
}
Till now is all good.
Except that when the user opens a new tab in the browser and specify a DIFFERENT id, for example test.xhtml?id=300 . the Session bean override the current values of the previous parameter 200, with the new id 300 values.
So my question is how can I use a session bean and deal with many tabs with different parameters? How can I have a session bean for each tab? If this is not possible than what solution do people use for this kind of scenario ? Thanks.
A #SessionScope Bean is living as long as the users Session is active. (hence the name) - It is shared between Requests and Views, which is the "Problem" you are facing.
A #RequestScope Bean will be recreated upon every request (No Matter if first-Access or Ajax-Request), which is possible to use for your usecase (reloading data based on resubmitted IDs), but can be optimized. (This would be a traditional Request/Response-Model as known from PHP - JSF offers a better option)
Your case perfectly matches the #ViewScope. One Bean per View, living as long as the View is present. This would allow you to open an (almost) infinite amount of different Views (hence, the name), each having it's individual set of BackingBeans as long as they are #ViewScope. Multiple "Views" of the same page are possible, each View will maintain the reference to it's dedicated View-Scoped-Beans. (In your example: 2 opened text.xhtml pages and therefore 2 active instances of TestBean, each having its own ID)
The behaviour of your application is correct. Please read the section about Scopes of The Java EE 6 Tutorial.
Your application has created a session scoped bean for the current user and it will be used by all request for such user. Any variable created in such bean will be shared by any tab the user opens.
If you expect the user to interact on multiple tabs with different values for the same variable, consider using a request scoped bean.
I recently read this article from Neil Griffin Making Distinctions Between Different Kinds of JSF Managed-Beans and it got me thinking about the distinction between different beans in my own application. To quickly summarise the gist:
Model Managed-Bean: This type of managed-bean participates in the
"Model" concern of the MVC design pattern. When you see the word
"model" -- think DATA. A JSF model-bean should be a POJO that follows
the JavaBean design pattern with getters/setters encapsulating
properties.
Backing Managed-Bean: This type of managed-bean participates in the
"View" concern of the MVC design pattern. The purpose of a
backing-bean is to support UI logic, and has a 1::1 relationship with
a JSF view, or a JSF form in a Facelet composition. Although it
typically has JavaBean-style properties with associated
getters/setters, these are properties of the View -- not of the
underlying application data model. JSF backing-beans may also have JSF
actionListener and valueChangeListener methods.
Controller Managed-Bean: This type of managed-bean participates in
the "Controller" concern of the MVC design pattern. The purpose of a
controller bean is to execute some kind of business logic and return a
navigation outcome to the JSF navigation-handler. JSF controller-beans
typically have JSF action methods (and not actionListener methods).
Support Managed-Bean: This type of bean "supports" one or more views
in the "View" concern of the MVC design pattern. The typical use case
is supplying an ArrayList to JSF h:selectOneMenu drop-down
lists that appear in more than one JSF view. If the data in the
dropdown lists is particular to the user, then the bean would be kept
in session scope.
Utility Managed-Bean: This type of bean provides some type of
"utility" function to one or more JSF views. A good example of this
might be a FileUpload bean that can be reused in multiple web
applications.
This made sense to me and for the past few hours I have been refactoring my code and came up with the following with respect to the user login:
The AuthenticationController is an example of a Controller Managed-Bean. It is request-scoped and features two getters and setters for setting a username and password, and two navigation methods, authenticate and logout, navigating the user to either their private area upon successful login, or back to the main page when logging out.
The UserBean is an example of a Support Managed-Bean. It is session-scoped and features an instance of User class (which would be null when you are not authenticated) with a getter and setter, nothing more.
The AuthenticationController has this user as a managed property (#ManagedProperty(value = "#{userController.user} private User user;). Upon successful authentication, the AuthenticationController would set the managed property to the actual user instance with the corresponding username that was used for the login.
Any new beans would be able to grab the user as a managed property as well and pull the data they need, such as group membership for instance, if the User class would feature a list with group names.
Would this way be the proper way to go about with regard to the seperation of concerns?
This is a very subjective question. I personally disagree that article and find that it's giving really bad advice to starters.
Model Managed-Bean: This type of managed-bean participates in the "Model" concern of the MVC design pattern. When you see the word "model" -- think DATA. A JSF model-bean should be a POJO that follows the JavaBean design pattern with getters/setters encapsulating properties.
I would absolutely not make or call it a managed bean. Just make it a property of a #ManagedBean. For example a DTO or JPA #Entity.
Backing Managed-Bean: This type of managed-bean participates in the "View" concern of the MVC design pattern. The purpose of a backing-bean is to support UI logic, and has a 1::1 relationship with a JSF view, or a JSF form in a Facelet composition. Although it typically has JavaBean-style properties with associated getters/setters, these are properties of the View -- not of the underlying application data model. JSF backing-beans may also have JSF actionListener and valueChangeListener methods.
This way you keep duplicating and mapping the properties of the entity in the managed bean. This makes no sense to me. As said, just make the entity a property of the managed bean and let the input fields refer it directly like #{authenticator.user.name} instead of #{authenticator.username}.
Controller Managed-Bean: This type of managed-bean participates in the "Controller" concern of the MVC design pattern. The purpose of a controller bean is to execute some kind of business logic and return a navigation outcome to the JSF navigation-handler. JSF controller-beans typically have JSF action methods (and not actionListener methods).
This describes the #RequestScoped/#ViewScoped #ManagedBean class pretty much. Whether event listener methods are allowed or not depends on whether they are specific to the view which is tied to the bean and/or are for their job dependent on the bean's state. If they are, then they belongs in the bean. If not, then they should be a standalone implementation of any FacesListener interface, but definitely not a managed bean.
Support Managed-Bean: This type of bean "supports" one or more views in the "View" concern of the MVC design pattern. The typical use case is supplying an ArrayList to JSF h:selectOneMenu drop-down lists that appear in more than one JSF view. If the data in the dropdown lists is particular to the user, then the bean would be kept in session scope.
Fine. For application wide data like dropdown lists just use an #ApplicationScoped bean and for session wide data like logged-in user and its preferences just use a #SessionScoped one.
Utility Managed-Bean: This type of bean provides some type of "utility" function to one or more JSF views. A good example of this might be a FileUpload bean that can be reused in multiple web applications.
This makes not really sense to me. Backing beans are usually tied to single views. This sounds too much like an ActionListener implementation which is to be used by <f:actionListener> in command components to your choice. Definitely not a managed bean.
For kickoff examples of the right approach, see also:
Hello World example in Our JSF wiki page
"Bookstore CRUD" example in this answer
"Master-detail" example in this answer
JSF Service Layer
Communication in JSF 2
I have three screens(views) associated with separate managed beans for each view.
And, I have a common pop-up dialog which can be opened in all the views.
Can I define a managedbean separately for the pop-up with state #NoneScoped; and maintain an instance of it in each parent bean?? or
Do I need to maintain pop-up data in all three parent views?
Please, suggest me the best practice.
I think this is what you are looking for (check out the answer by BalusC) -
Whats the correct way to create multiple instances of managed beans in JSF 2.0
And since you are using #NoneScoped (unlike #RequestScoped in the above question), I also recommend you to look at this answer by BalusC (about #NoneScoped) -
what is none scope bean and when to use it?
And according to this answer, you can't maintain any instances of a managedbean that is none-scoped, as they are garbaged as soon as they are used.
So, in your case since you have three separate views, for each view, the bean is constructed and used to build the view and garbaged. (Looks like it does not even last for a request cycle). When you request another view, it will be a separate instance.
To have multiple intances of a bean, you can have three properties in a Session-Scoped been (to make them survive across multiple views).
#ManagedBean
#SessionScoped
public class Parent {
private Child child1;
private Child child2;
private Child child3;
// ...
}
Hey guys. I'm designing a site that uses the Icefaces framework. I've been reading a book called Real World Java EE patterns. I'm kind of confused how to layout the pages. Normally I would have just a POJO class implement serializable for a bean. This bean would then back each page. With a single page design I'm going to have a bunch of elements on the page. Datatables, trees, inputs, calendars etc. Is it normal or best practice to have separate beans for each datatable, calendar, etc or put that all in one bean? I'm not sure how to approach this. Right now each element is a bean and I'm using the #Inject annotation to have the data table talk to the tree and vise versa. This creates really bad code and if I put this as a member of the class I will get a circular reference because the data table bean has to inject the calendar and the calendar has to inject the data table.
Thanks for any help.
I tend to use a single bean per <h:form> or at least per view (XHTML/JSP file). Any related beans will just be injected in this particular "main" bean (and thus not among each other).