dev@javaserverfaces.java.net

Re: Flash scope still broken? (Mojarra 2.3m04)

From: Lenny Primak <lprimak_at_hope.nyc.ny.us>
Date: Wed, 2 Mar 2016 18:13:24 -0600

Arjan, thanks for the pointer.
I actually figured out where the error is coming from, and it’s not from this code.
The cookie is being written (and the error appears) within exception handling,
but I don’t think that code can be moved into the correct phase.

Here is my use case:
- User is using Ajax screen
- User is “remembered” i.e. remember me cookie is set: http://shiro.apache.org/web.html#Web-RememberMeServices
- User’s session times out, but used isn’t forced to log back in b/c “remembered”
- ViewExpiredException occurs
- ViewExpiredException handler is captured and it puts a value into flash saying that the session is expired on the next request
- User is redirected back to the same view (view is reloaded)
- A Pop-up message (PrimeFaces p:growl) is used to flash a message that their session expired
- User keeps using the same Ajax screen with a new session

Apparently, the exception handling that’s setting the flash isn’t at the “proper phase”
but I don’t know of a way to get it in the “proper phase”

https://github.com/flowlogix/flowlogix/blob/17c9cf941f01a120ae466c20ab0e684c5610250e/flowlogix-jee/src/main/java/com/flowlogix/ui/ViewExpiredExceptionHandlerFactory.java

web.xml:
   <filter>
        <filter-name>facesExceptionFilter</filter-name>
        <filter-class>org.omnifaces.filter.FacesExceptionFilter</filter-class>
        <async-supported>true</async-supported>
    </filter>
    <filter-mapping>
        <filter-name>facesExceptionFilter</filter-name>
        <servlet-name>Faces Servlet</servlet-name>
    </filter-mapping>
    <filter>
        <filter-name>gzipResponseFilter</filter-name>
        <filter-class>org.omnifaces.filter.GzipResponseFilter</filter-class>
        <async-supported>true</async-supported>
    </filter>
    <filter-mapping>
        <filter-name>gzipResponseFilter</filter-name>
        <servlet-name>Faces Servlet</servlet-name>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>ERROR</dispatcher>
    </filter-mapping>
    <filter>
        <filter-name>characterEncodingFilter</filter-name>
        <filter-class>org.omnifaces.filter.CharacterEncodingFilter</filter-class>
        <async-supported>true</async-supported>
    </filter>
    <filter-mapping>
        <filter-name>characterEncodingFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>ERROR</dispatcher>
    </filter-mapping>

faces-config.xml:
    <factory>
        <exception-handler-factory>org.primefaces.application.exceptionhandler.PrimeExceptionHandlerFactory</exception-handler-factory>
        <exception-handler-factory>com.flowlogix.ui.ViewExpiredExceptionHandlerFactory</exception-handler-factory>
    </factory>


> On Mar 2, 2016, at 3:18 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> Hi,
>
> On Wed, Mar 2, 2016 at 9:49 PM, Lenny Primak <lprimak_at_hope.nyc.ny.us <mailto:lprimak_at_hope.nyc.ny.us>> wrote:
> So then what is the right way to access flash from a component?
> All other documentation and results of internet searches point to solutions from pages, not components.
> Specifically, I need to access the flash from the layout component
>
> Not 100% sure about the Flash, but as for doing things pre-render time you may want to look at the Cache component I did for OmniFaces. There I subscribe from the ctor to several events. See here: https://github.com/omnifaces/omnifaces/blob/2.2/src/main/java/org/omnifaces/component/output/Cache.java#L159 <https://github.com/omnifaces/omnifaces/blob/2.2/src/main/java/org/omnifaces/component/output/Cache.java#L159>
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>> On Mar 2, 2016, at 2:33 PM, manfred riem <manfred.riem_at_oracle.com <mailto:manfred.riem_at_oracle.com>> wrote:
>>
>> Hi Lenny,
>>
>> PreRenderComponent is triggered during RENDER_RESPONSE phase just before
>> a specific component is rendered. If you are using the Flash then it indeed is
>> at the wrong time.
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>> On 2/29/16, 12:49 PM, Lenny Primak wrote:
>>>
>>> I would think that preRenderComponent also satisfies INVOKE_APPLICATION requirement.
>>> I’ve been doing a lot of reading about this few years ago and I think I got that one correctly.
>>>
>>> <?xml version='1.0' encoding='UTF-8' ?>
>>> <!DOCTYPE html [ <!ENTITY nbsp "&#160;"> ]>
>>> <html xmlns="http://www.w3.org/1999/xhtml <http://www.w3.org/1999/xhtml>"
>>> xmlns:ui="http://xmlns.jcp.org/jsf/facelets <http://xmlns.jcp.org/jsf/facelets>"
>>> xmlns:h="http://xmlns.jcp.org/jsf/html <http://xmlns.jcp.org/jsf/html>"
>>> xmlns:jsf="http://xmlns.jcp.org/jsf <http://xmlns.jcp.org/jsf>"
>>> xmlns:f="http://xmlns.jcp.org/jsf/core <http://xmlns.jcp.org/jsf/core>"
>>> xmlns:p="http://xmlns.jcp.org/jsf/passthrough <http://xmlns.jcp.org/jsf/passthrough>"
>>> xmlns:baw="http://xmlns.jcp.org/jsf/composite/components <http://xmlns.jcp.org/jsf/composite/components>"
>>> xmlns:flowlogix="http://flowlogix.com/ui <http://flowlogix.com/ui>"
>>> xmlns:c="http://xmlns.jcp.org/jsp/jstl/core <http://xmlns.jcp.org/jsp/jstl/core>"
>>> xmlns:pf="http://primefaces.org/ui <http://primefaces.org/ui>"
>>> xmlns:o="http://omnifaces.org/ui <http://omnifaces.org/ui>">
>>> <head jsf:id="head">
>>> <f:view transient="#{empty transient? 'true' : transient}"/>
>>> <f:event type="preRenderComponent" listener="#{layout.setPageType(pageType)}”/>
>>> ………………
>>>
>>> @Model @Getter
>>> public class Layout
>>> {
>>> public enum PageType { Index, Pallets, Logistics }
>>>
>>>
>>> public void setPageType(PageType pageType)
>>> {
>>> -----------------
>>> if (Faces.hasSession() && !Faces.getSession(false).isNew() && Boolean.TRUE.equals(Faces.getFlashAttribute(AttributeKeys.SESSION_EXPIRED_KEY)))
>>> {
>>> // below doesn’t get executed
>>> Faces.getContext().addMessage(AttributeKeys.SESSION_EXPIRED_KEY,
>>> new FacesMessage(FacesMessage.SEVERITY_INFO,
>>> null, "Your Session has Expired"));
>>> }
>>> ...
>>>
>>>> On Feb 29, 2016, at 12:42 PM, arjan tijms <arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Monday, February 29, 2016, Lenny Primak <lprimak_at_hope.nyc.ny.us <mailto:lprimak_at_hope.nyc.ny.us>> wrote:
>>>> The funny thing is that I am not using flash at all.
>>>> The only Flash-related call in the process here is a getFlashAttribute within
>>>> preRenderComponent event.
>>>>
>>>> That probably counts for "using The Flash" I'm afraid.
>>>>
>>>> It's conceptually a bit weird though that by just reading and never writing the code still wants to write out the flash cookie.
>>>>
>>>> Kind regards,
>>>> Arjan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I don’t see how this could affect things at all.
>>>> This only happens for (unconfirmed) very large pages.
>>>>
>>>> > On Feb 29, 2016, at 11:08 AM, manfred riem <manfred.riem_at_oracle.com <>> wrote:
>>>> >
>>>> > Hi Lenny,
>>>> >
>>>> > You are using the Flash too late in the process, aka during render.
>>>> >
>>>> > If you do not want this problem to show up please use the Flash during INVOKE_APPLICATION.
>>>> >
>>>> > Thanks!
>>>> >
>>>> > Kind regards,
>>>> > Manfred Riem
>>>> >
>>>> > On 2/26/16, 11:41 PM, Lenny Primak wrote:
>>>> >> I am using Mojarra 2.3m04, and Flash scope is still broken.
>>>> >> I am getting this error:
>>>> >>
>>>> >> -----
>>>> >> JSF1095: The response was already committed by the time we tried to set the outgoing cookie for the flash. Any values stored to the flash will not be available on the next request.
>>>> >> ——
>>>> >>
>>>> >> The weird thing is that I am not even putting anything into flash scope, and there is no flash cookie in the browser.
>>>> >>
>>>> >> I put this snippet in web.xml:
>>>> >> <context-param>
>>>> >> <param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
>>>> >> <param-value>32768</param-value>
>>>> >> </context-param>
>>>> >>
>>>> >> which solves this problem 99% of the time, but for some large pages, the issue persists.
>>>> >>
>>>> >> I have no way to reproduce this as this happens very, very rarely, and only in production
>>>> >> (yes, I am using 2.3m04 in production and it works great!)
>>>> >
>>>>
>>>
>
>