2010-01-22 7 views
9

Per gestire ViewExpiredException in JSF, ho codificatoViewExpiredException JSF

<error-page> 
    <exception-type>javax.faces.application.ViewExpiredException</exception-type> 
    <location>/error.html</location> 
</error-page> 

<session-config> 
    <session-timeout>1</session-timeout> 
</session-config> 

in web.xml.

In error.html Ho reindirizzato alla pagina di accesso originale. Ma il problema è che il bean con scope di sessione non è stato eliminato anche alla sessione scaduta. C'è un modo per risolverlo?

risposta

7

La pagina di accesso è stata probabilmente richiesta dalla cache del browser. Disabilitalo creando un Filter che è legato allo FacesServlet e ha fondamentalmente le seguenti linee nel metodo doFilter(), in modo che non sia necessario ripeterlo su tutte le pagine che si desidera impedire di memorizzare nella cache.

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. 
response.setHeader("Pragma", "no-cache"); // HTTP 1.0. 
response.setDateHeader("Expires", 0); // Proxies. 
+0

Se utilizzo Facelet e ho un layout fisso, c'è qualche differenza nell'impostazione nell'intestazione o in un filtro? – RinaldoPJr

+0

@Rin: No, non c'è assolutamente alcuna differenza. Devi solo ricordare che le intestazioni delle risposte HTTP hanno sempre la precedenza su quelle impostate in meta. Quindi, se il server ha impostato alcune impostazioni predefinite nell'intestazione della risposta HTTP, queste sostituiranno quelle impostate in meta. Vedi anche http://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers/2068407#2068407 e http://stackoverflow.com/questions/ 10305718/avoid-back-button-on-jsfprimefaces-application/10305799 # 10305799 – BalusC

+0

Scusa, ho dimenticato di ringraziarti. :) E 'stato molto illuminante; – RinaldoPJr