Question

I have a problem with JSF’s FlashScope, note that I’m aware that the redirect should point to the same base path as the calling page.

My case, the action will be initialized when a client click a link from his/her email, then it will load a .xhtml (has a preRenderView event) page with a backing bean to check the parameters passed. When the parameters are wrong it must redirect to a new page with message.

The View:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:p="http://primefaces.org/ui">

    <f:metadata>
        <f:viewParam name="dummy" />
        <f:event listener="#{signupMaterialBean.initFromContext()}"
            type="preRenderView"></f:event>
    </f:metadata>

    <h:outputText value="#{signupMaterialBean.html}" escape="false"></h:outputText>

</ui:composition>

The Backing Bean:

public void initFromContext() {
    try {
        Map<String, String> params = facesContext.getExternalContext()
                .getRequestParameterMap();
        ...
    } catch (NullPointerException e) {      
        try {
            Message message = new Message();
            String msg = "Invalid parameters";
            message.setMessage(msg);

            JSFUtils.flashScope().put("message", message);

            facesContext.getExternalContext().redirect("message.xhtml");
            facesContext.responseComplete();
        } catch (IOException ioe) {
        }
    } catch (IOException e) {
    }
}

The redirect works, but the message save in FlashScope is gone. Any idea why the flash scope is being deleted or another way to do it?

message.xhtml

    <ui:define name="head"></ui:define>

    <ui:define name="content">
        <div class="box-middle-content faded">
            <div class="message">
                <h:outputText escape="false" value="#{flash.message.message}"></h:outputText>
                <br />
                <p>
                    <h:outputText value="#{msgs['message.footer']}" escape="false" />
                </p>
            </div>
        </div>
    </ui:define>
</ui:composition>

JSFUtils

public class JSFUtils {
    public static Flash flashScope() {
        return (FacesContext.getCurrentInstance().getExternalContext()
                .getFlash());
    }
}

Updated view:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:p="http://primefaces.org/ui"
    xmlns:of="http://omnifaces.org/functions">

    <f:metadata>
        <f:viewParam name="dummy"></f:viewParam>
        <f:event type="postInvokeAction"
            listener="#{signupMaterialBean.initFromContext}" />
    </f:metadata>

    <h:outputText value="#{signupMaterialBean.html}" escape="false"></h:outputText>

</ui:composition>

Answer 1

The <f:event type="preRenderView"> is too late to set a flash scoped attribute. The flash scope can’t be created when JSF is currently sitting in render response phase. You basically need to set the flash scoped attribute before render response phase. In spite of the name preRenderView, this event is actually fired during (the very beginning of) the render response phase.

You’d basically need to invoke the listener method during INVOKE_ACTION phase. As there’s no standard <f:event> type for this, you’d need to homegrow one. This is outlined in detail in this answer: Can't keep faces message after navigation from preRender.

You’d ultimately like to end up as:

<f:event listener="#{signupMaterialBean.initFromContext()}"
         type="postInvokeAction" />

Note that this event is already provided by OmniFaces. See also the InvokeActionEventListener showcase page which handles exactly this issue.

---

Unrelated to the concrete problem, the catch on NullPointerException is a huge code smell. Don’t catch runtime exceptions like that. Prevent them by performing nullchecking as if (foo != null) and so on. Also those empty catches on IOException are very bad. Remove them all and just add throws IOException to the method.

Further, the redirect path problem is fixed since Mojarra 2.1.14. So since that version you could safely redirect to a different base path.