5

We are using:

  • JSF 1.2-1.2_07-b03-FCS
  • JSTL 1_1-mr2 (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: 6.0

We have mainForm.jsp, filterForm.jsp, and externalForm.jsp views.

There is a button "Filter" on mainForm.jsp to transition to filterForm.jsp. It does that by a navigation rule:

<h:commandButton value="Filter" action="#{mainBean.filterData}" />

The mainBean.java code is:

public String filterData() {
    doStuff();
    return "filter";
}

This initially transitions correctly to filterForm.jsp. We can go back to the mainForm.jsp with the browser back button. We can do this repeatedly.

On mainForm.jsp we have a table (actually an ILog Gantt Chart, but we don't think that matters), with a "popup" menu on the chart bars. One of the menu options is to redirect to the externalForm.jsp.

Selecting the "redirect" triggers the following method in mainBean.java:

public void redirect(FacesMenuActionEvent event) {
    if (svr == null) {
        svr = new SetupURL(); // Simple code to set up the full URL
    }

    redirectUrl = svr.redirect(event);  // URL of externalForm.jsp
    svr.redirectData(redirectUrl);
}

This correctly works. The window transitions to externalForm.jsp.

If we press the browser back button on externalForm.jsp, we transition back to mainForm.jsp and things look OK.

If we then press the "Filter" button, the code does not execute the filterData() method, but instead it executes the redirect() method and we transition to the externalForm.jsp view, not the filterForm.jsp view.

Why does it do this and how do we force a call to filterData() instead?

******************************************************************************

BalusC - thank you for your solution.  With a few slight tweeks, it worked great.

The changes I made to web.xml are:

    <filter>
       <filter-name>noCacheFilter</filter-name>
       <filter-class>{my package name}.CacheControlFilter</filter-class>
    </filter>
    <filter-mapping>
       <filter-name>noCacheFilter</filter-name>
       <url-pattern>/faces/*</url-pattern>
    </filter-mapping>




Also, I found another solution:

faces-config.xml add:

    <lifecycle>
        <phase-listener id="nocache">{my package name}.
        CacheControlPhaseListener</phase-listener>
    </lifecycle>    


Create file CacheControlPhaseListener.java:

package {my package name};

import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import javax.servlet.http.HttpServletResponse;

public class CacheControlPhaseListener implements PhaseListener {

    public PhaseId getPhaseId() {
        return PhaseId.RENDER_RESPONSE;
    }

    public void afterPhase(PhaseEvent event) {
    }

    public void beforePhase(PhaseEvent event) {
        FacesContext facesContext = event.getFacesContext();
        HttpServletResponse response = (HttpServletResponse) facesContext
                .getExternalContext().getResponse();
        response.addHeader("Pragma", "no-cache");
        response.addHeader("Cache-Control", "no-cache");
        // Stronger according to blog comment below that references HTTP spec
        response.addHeader("Cache-Control", "no-store");
        response.addHeader("Cache-Control", "must-revalidate");
        // some date in the past
        response.addHeader("Expires", "Mon, 8 Aug 2006 10:00:00 GMT");
    }
}

Both seem to work.



Thanks,
John
John K
  • 111
  • 1
  • 4
  • 11

1 Answers1

12

The browser back button requests the result page from the browser cache. It does not request a fresh new page from the server. In your particular case, most likely the cached page contained a currently invalidated JSF view state.

Best fix is to instruct the browser to not cache the dynamic JSF pages, but instead requests it straight from the server everytime. You can do that with help of a Filter which has the following lines in the doFilter() method:

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException {
    HttpServletResponse res = (HttpServletResponse) response;
    res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
    res.setHeader("Pragma", "no-cache"); // HTTP 1.0.
    res.setDateHeader("Expires", 0); // Proxies.
    chain.doFilter(request, response);
}

Map this on the same <servlet-name> of the FacesServlet in web.xml. E.g.

<filter>
   <filter-name>noCacheFilter</filter-name>
   <filter-class>com.example.NoCacheFilter</filter-class>
</filter>
<filter-mapping>
   <filter-name>noCacheFilter</filter-name>
   <servlet-name>facesServlet</servlet-name>
</filter-mapping>
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Using the same URL pattern as the `FacesServlet` can also, yes. If the servlet name mapping didn't work out for you, then you apparently just specified the wrong servlet name. Sometimes it's just `Faces Servlet`. Just look at that in your `web.xml`. The `PhaseListener` is too clumsy for this particular purpose, don't ever think about this. You are not interested in manipulating the JSF lifecycle or component tree. You're only interested in modifying the HTTP response. For that a `Filter` is the best suit. – BalusC Nov 18 '11 at 22:03
  • Yes, I see now. I went with your solution anyway, but thank you for the explanation as to what was wrong with the PhaseListener solution. – John K Nov 21 '11 at 15:09
  • @BalusC I think the first entry should a not a , correct? I was going to edit your answer to not have the two 'filter-mapping' entries in the sample code (likely just a typo). – Brian Feb 02 '12 at 15:14