0
votes

I have managed bean by name studentManagedBean. In that bean I have used post construct to intialize studentsList. In another managed bean testbean I was using FacesContext.getCurrentInstance().getExternalContext().invalidateSession(); and redirecting to page students.xhtml where I used to display students.

My question is when I used the FacesContext.getCurrentInstance().getExternalContext().invalidateSession(); and redirected to student.xtml page, init method(post construct) used to call two times. When I commented the above line, init method(post construct) now calls only one time.

can any one tell me what is this invalidate session will exactly do.

  @ManagedBean(name = "studentManagedBean" )
    @SessionScoped
    public class StudentManagedBean implements Serializable {


        private List<SBean> stud;



        @PostConstruct
        private void init(){
            this.stud=dao.getAllStudInfo();
        }





 @ManagedBean(name = "testBean" )
    @SessionScoped
    public class TestBean implements Serializable {

public String navigate(String name){
        if(name.equals("Add student")){
    FacesContext.getCurrentInstance().getExternalContext().invalidateSession();
             return  "student";

        }
1

1 Answers

0
votes

Apparently, the session scoped bean StudentManagedBean is also referenced in the current view. When the view get built/restored, it may create the bean if it's referenced during view build time. But if you're invalidating the session thereafter, the session scoped bean get destroyed (obviously, since it's stored in the session scope) and will be re-created again when the target view still references it during rendering of the view.

This must make completely sense. If you don't want that the bean is created before you invalidate the session, simply don't reference it anywhere in the current view, either directly in the view, or indirectly as a managed property or a programmatic EL evaluation of another bean which is directly referenced in the current view.

If you can't immediately figure out where it's been referenced, just put a debug breakpoint in the bean's constructor and explore the call stack for the who/what/why.