1

I have: SP/JSF web page DelegateBean.jsp Associated bean DelegateBean.java

DelegateBean.java:

String msg;

public DelegateBean() {}
  clearMsg();
  ...
}

public void clearMsg() {
   msg = "":
}
.. other methods

When the page first opens up, constructor DelegateBean() is called.

If the operator presses a command button on the page, which refreshes the page, the constructor is not called (nor should it be);

If the operator presses the Back button and then the Forward button, the constructor is not called (it probably should not be).

The question is: how to force clearMsg() to execute when reentered from a Forward button (another web page), but NOT execute when reentered from itself (command button pressed)?

Is there a good (simple) example?

Thanks, John

John K
  • 111
  • 1
  • 4
  • 11
  • Given that you're using legacy JSP, you're thus most likely using JSF 1.x. Is this assumption correct? If so, which component libraries are you all using? – BalusC Oct 31 '12 at 23:56
  • Is it just about `clearmessage()` getting called ? Or having a fresh bean all together ? – Mukul Goel Nov 01 '12 at 00:04
  • BalusC - I should have indicated: JSF 1.2-1.2_07-b03-FCS, JSTL 1_1-mr2 (JViews special build), Java 1.6.0_22-b04, Eclipse 3.6.0 (Helios), Tomcat 6.0.28 (needs to run also on Weblogic), IE 7.0.5730.13, Firefox: several newer versions. – John K Nov 01 '12 at 15:28
  • Mukul Goel - It is just about clearMessage() getting called on initialization and when reentered after a back, then forward is executed. Not called when a command button is pressed (which refreshes the display). – John K Nov 01 '12 at 15:30
  • i think seeing your requirement, simplest way would be to add an explicit call to `clearmessage() ` inside action of `forward button` – Mukul Goel Nov 02 '12 at 17:20

2 Answers2

1

It look's like your Managed Bean is @SessionScoped and the constructor will be called only the first time the user access to a page when the bean is used.

In JSF 2, this can be achieved changing the Managed Bean to @ViewScoped.

@ManagedBean
@ViewScoped
public class Bean {

    public Bean() {
    }

    @PostConstruct
    public void init() {
        clearMsg();
    }
}

BalusC gives a good explanation about JSF Managed Bean scopes in this answer: How to choose the right bean scope?. Also, I recommend you to read the link at the bottom of the answer to have a better understanding of these concepts.


In JSF 1.x, you should configure the Managed Bean to request scope in the faces-config.xml file and call the clearMsg in the @PostConstruct public void init method. Note that this means that the clearMsg method will be invoked on every request that involves creating the managed bean class (even ajax requests). In order to solve the problem, you should provide more info about how and when you call this bean in your JSF code. By default, you can solve this by setting a flag in the session and check against this flag before calling the clearMsg method (or the methods you only need to call once).

public class Bean {

    public Bean() {
    }

    @PostConstruct
    public void init() {
        HttpSession session = ((HttpRequest)FacesContext.getCurrentInstance().
            getExternalContext().getRequest()).getSession();
        if (session.getAttribute("flag") == null) {
            clearMsg();
            //other methods...
        }
    }
}

Faces configuration

<managed-bean>
    <managed-bean-name>bean</managed-bean-name>
    <managed-bean-class>your.package.Bean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>

There's a way to simulate the request scope Managed Bean into a @ViewScoped by using @KeepAlive annotation from RichFaces 3. Take into account that the bean will be alive until you change the view by making an explicit redirect. Based on this, the code would be like this:

@KeepAlive
public class Bean {

    public Bean() {
    }

    @PostConstruct
    public void init() {
        //no need to use session flags
        clearMsg();
        //other methods...
    }
}
Community
  • 1
  • 1
Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
  • OP's question history confirms JSF 1.2 by the way: http://stackoverflow.com/questions/8185245/redirect-side-effects-when-using-browser-back-button – BalusC Nov 01 '12 at 00:23
  • op confirms , that changing scope aint an option. so your answer , a nice one, becomes invalid here. :-( – Mukul Goel Nov 02 '12 at 17:27
  • @MukulGoel OP can change the scope of the bean for `@ViewScoped` or the equivalent in JSF 1.2. In the extremely case that Op can't, the only way to solve the problem is having another managed bean, but that depends only of OP decision. AFAIK, this answer solves the problem stated in the question, if OP post the exact problem, the answer would be more accurate :). – Luiggi Mendoza Nov 02 '12 at 17:34
0

What is the scope of bean in faces-config.xml ?

As you are describing the problem , looks like it is session , because of which bean is being constructed per session and not request.

Change the scope to request and you probably should be good.

UPDATE as per discussion with @BalusC

The request scope mentioned above conflicts with the requirement not to be called from the same page

If you are on jsf 2.x , change scope to viewscope.

Update #2

i think seeing your requirement, jsf 1.2 and can not change scope of bean.

simplest way would be to add an explicit call to clearmessage() inside action of forward button

Mukul Goel
  • 8,387
  • 6
  • 37
  • 77
  • This conflicts *"If the operator presses a command button on the page, which refreshes the page, the constructor is not called (nor should it be);"* – BalusC Oct 31 '12 at 23:56
  • @BalusC yup you are correct. Would it be a good design to have bean in session scope and call the constructor explicitly from the `forward` action. Not sure. :-D – Mukul Goel Nov 01 '12 at 00:01
  • 1
    If OP were using JSF2, you could just have used the view scope. But this doesn't exist in JSF 1.x, although some JSF 1.x component libraries have solutions to achieve the same. – BalusC Nov 01 '12 at 00:03
  • BalusC, Mukul Goel - It is a session bean. Due to the current place in the development/test cycle, it would be hard to change the scope. – John K Nov 01 '12 at 15:38