javax.face.application.ViewExpiredException: la vue n'a pas pu être restaurée

Introduction

le ViewExpiredException sera lancé à chaque fois que le javax.faces.STATE_SAVING_METHOD est défini à server (par défaut) et l'utilisateur final envoie une requête HTTP POST sur une vue via <h:form> avec <h:commandLink> , <h:commandButton> ou <f:ajax> , alors que l'état de vue associé n'est plus disponible dans la session.

l'état de vue est identifié comme la valeur d'un champ d'entrée caché javax.faces.ViewState du <h:form> . Avec l'état méthode d'enregistrement définie à server , elle contient seulement L'ID d'état de la vue qui renvoie à un État de vue sérialisé dans la session. Ainsi, lorsque la session est Expirée pour une raison quelconque (soit du côté du serveur ou du côté du client, soit le cookie de session n'est plus maintenu pour une raison quelconque dans le navigateur, ou en appelant HttpSession#invalidate() dans le serveur, ou en raison d'un bogue spécifique au serveur avec des cookies de session comme connu dans WildFly ), alors l'état de vue sérialisé n'est plus disponible en la session et l'utilisateur final obtiendront cette exception. Pour comprendre le fonctionnement de la session, Voir aussi Comment fonctionnent les servlets? L'instanciation, les sessions, les variables partagées et le multithreading .

il y a aussi une limite sur le nombre de vues que JSF stockera dans la session. Lorsque la limite est atteint, alors la moins récemment utilisée sera expiré. Voir aussi com.soleil.face.numberOfViewsInSession vs com.soleil.face.numberOfLogicalViews .

avec la méthode de sauvegarde d'état définie à client , le champ d'entrée caché javax.faces.ViewState contient à la place l'état de vue sérialisé complet, de sorte que l'utilisateur final n'obtiendra pas un ViewExpiredException lorsque la session expire. Cela peut toutefois se produire dans un environnement de cluster ("erreur: MAC n'a pas Vérifié" est symptomatique) et/ou lorsqu'il y a un délai spécifique à l'implémentation dans l'état client configuré et / ou lorsque le serveur réinvente la clé AES pendant redémarrer, voir aussi obtenir ViewExpiredException dans l'environnement clustered alors que la méthode de sauvegarde d'état est définie au client et que la session utilisateur est valide comment la résoudre.

quelle que soit la solution, assurez-vous de faire et non utilisez enableRestoreView11Compatibility . il ne restaure pas du tout l'état de vue original. Il recrée essentiellement la vue et toutes les vues scoped beans associées à partir de zéro et donc perdre toutes les données originales (état). Comme l'application se comporter d'une manière confuse ("Hey, où sont mes valeurs d'entrée..??"), c'est très mauvais pour l'expérience utilisateur. Utilisez plutôt stateless views ou <o:enableRestorableView> à la place de sorte que vous pouvez le gérer sur une vue spécifique seulement au lieu de sur toutes les vues.

quant au pourquoi JSF doit sauver l'état de vue, tête à cette réponse: pourquoi JSF sauve l'état des composants UI sur le serveur?

éviter ViewExpiredException sur la navigation de page

pour éviter ViewExpiredException lorsque , par exemple, la navigation de retour après la déconnexion lorsque l'état de sauvegarde est défini à server , il ne suffit pas de rediriger la requête POST après la déconnexion. Vous devez également donner des instructions au navigateur pour et non cache les pages JSF dynamiques, sinon le navigateur peut les afficher à partir du cache au lieu d'en Demander une nouvelle du serveur lorsque vous envoyez une demande GET sur elle (par exemple par bouton retour).

le champ caché javax.faces.ViewState de la page Mise en cache peut contenir une valeur d'ID d'état de vue qui n'est plus valide dans la session en cours. Si vous utilisez POST (command links/buttons) au lieu de GET (regular links/buttons) pour la navigation page-à-page, et cliquez sur un tel lien/bouton de commande sur la page Mise en cache, cela échouera à son tour avec un ViewExpiredException .

pour lancer une redirection Après déconnexion dans JSF 2.0, soit ajouter <redirect /> à la <navigation-case> en question (le cas échéant), ou ajouter ?faces-redirect=true à la valeur outcome .

<h:commandButton value="Logout" action="logout?faces-redirect=true" />

ou

public String logout() {
    // ...
    return "index?faces-redirect=true";
}

pour indiquer au navigateur de ne pas mettre en cache les pages JSF dynamiques, créer un Filter qui est mappé sur le nom de servlet du FacesServlet et ajoute les en-têtes de réponse nécessaires pour désactiver le cache du navigateur. Par exemple:

@WebFilter(servletNames={"Faces Servlet"}) // Must match <servlet-name> of your FacesServlet.
public class NoCacheFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) request;
        HttpServletResponse res = (HttpServletResponse) response;

        if (!req.getRequestURI().startsWith(req.getContextPath() + ResourceHandler.RESOURCE_IDENTIFIER)) { // Skip JSF resources (CSS/JS/Images/etc)
            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);
    }

    // ...
}

eviter ViewExpiredException sur la page rafraîchissement 1519730920"

pour éviter ViewExpiredException lors du rafraîchissement de la page courante lorsque l'état de sauvegarde est défini à server , vous devez non seulement vous assurer que vous effectuez la navigation de page à page exclusivement par GET (liens/boutons réguliers), mais vous devez également vous assurer que vous utilisez exclusivement ajax pour soumettre les formulaires. Si vous soumettez le formulaire de manière synchrone (Non-ajax) de toute façon, alors vous feriez mieux soit de rendre la vue apatride (voir la section suivante), ou d'envoyer une redirection après POST (voir section précédente).

ayant un ViewExpiredException sur la page refresh est en configuration par défaut un cas très rare. Cela ne peut se produire que lorsque la limite de la quantité de vues que JSF stockera dans la session est atteinte. Ainsi, cela ne se produira que si vous avez défini manuellement cette limite beaucoup trop basse, ou que vous créez continuellement de nouvelles vues en arrière-plan (par exemple par un sondage mal implémenté). Voir aussi com.soleil.face.numberOfViewsInSession vs COM.soleil.face.numberOfLogicalViews . Une autre cause est d'avoir des bibliothèques JSF dupliquées dans classpath runtime en conflit les unes avec les autres. La procédure correcte pour installer JSF est décrite dans notre page wiki JSF .

Handling ViewExpiredException

quand vous voulez gérer un inévitable ViewExpiredException après une action de poste sur une page arbitraire qui a déjà été ouvert dans un onglet/fenêtre de navigateur pendant que vous êtes connecté dans un autre onglet/fenêtre, puis vous souhaitez spécifier un error-page pour que web.xml qui va à un "Votre session a expiré". Par exemple:

<error-page>
    <exception-type>javax.faces.application.ViewExpiredException</exception-type>
    <location>/WEB-INF/errorpages/expired.xhtml</location>
</error-page>

utilisez si nécessaire un en-tête meta refresh dans la page d'erreur dans le cas où vous avez l'intention de réellement rediriger plus loin à la page d'accueil ou de connexion.

<!DOCTYPE html>
<html lang="en">
    <head>
        <title>Session expired</title>
        <meta http-equiv="refresh" content="0;url=#{request.contextPath}/login.xhtml" />
    </head>
    <body>
        <h1>Session expired</h1>
        <h3>You will be redirected to login page</h3>
        <p><a href="#{request.contextPath}/login.xhtml">Click here if redirect didn't work or when you're impatient</a>.</p>
    </body>
</html>

(le 0 dans content représente le nombre de secondes avant rediriger, 0 signifie ainsi "rediriger immédiatement", vous pouvez utiliser par exemple 3 pour laisser le navigateur attendre 3 secondes avec la redirection)

noter que le traitement des exceptions durant les demandes ajax nécessite un ExceptionHandler spécial . Voir aussi délai d'expiration de Session et ViewExpiredException la manipulation sur le JSF/PrimeFaces requête ajax . Vous pouvez trouver un exemple en direct à OmniFaces FullAjaxExceptionHandler vitrine page (ce couvre également les requêtes non-ajax).

notez aussi que votre page d'erreur" générale "doit être mappée sur <error-code> de 500 au lieu de <exception-type> de par ex. java.lang.Exception ou java.lang.Throwable , sinon toutes les exceptions emballées dans ServletException comme ViewExpiredException se retrouveraient toujours sur la page d'erreur générale. Voir aussi ViewExpiredException montré en java.lang.Throwable erreur de la page web.xml .

<error-page>
    <error-code>500</error-code>
    <location>/WEB-INF/errorpages/general.xhtml</location>
</error-page>

Apatrides vues

une alternative complètement différente est d'exécuter des vues JSF en mode apatride. De cette façon rien de l'état JSF ne sera sauvé et les vues n'expireront jamais, mais seront reconstruites à partir de zéro sur chaque demande. Vous pouvez activer les vues apatrides en paramétrant l'attribut transient de <f:view> à true :

<f:view transient="true">

</f:view>

ainsi le champ caché javax.faces.ViewState obtiendra une valeur fixe de "stateless" en Mojarra (n'ont pas vérifié MyFaces à ce point). Notez que cette fonctionnalité était introduit dans Mojarra 2.1.19 et 2.2.0 et n'est pas disponible dans les versions plus anciennes.

la conséquence est que vous ne pouvez plus utiliser view scoped beans. Ils vont maintenant se comporter comme des demandes scoped beans. Un des inconvénients est que vous devez suivre l'état vous-même en jouant avec des entrées cachées et/ou des paramètres de requête libres. Principalement les formulaires avec champs d'entrée avec rendered , readonly ou disabled les attributs qui sont contrôlés par des événements ajax seront affectés.

notez que le <f:view> n'a pas nécessairement besoin d'être unique tout au long de la vue et/ou résident dans le modèle principal seulement. Il est aussi tout à fait légal de faire une déclaration et de l'insérer dans un client de modèle. Il "étend" fondamentalement le parent <f:view> puis. Par exemple: dans le modèle principal:

<f:view contentType="text/html">
    <ui:insert name="content" />
</f:view>

et dans le modèle client:

<ui:define name="content">
    <f:view transient="true">
        <h:form>...</h:form>
    </f:view>
</f:view>

vous pouvez même envelopper le <f:view> dans un <c:if> pour le rendre conditionnel. Notez que cela s'applique sur les ensemble , non seulement sur le contenu imbriqué, comme le <h:form> dans l'exemple ci-dessus.

Voir aussi

• ViewExpiredException montré en java.lang.Throwable erreur de la page web.xml
• vérifier si la session existe JSF
• délai d'expiration de Session et ViewExpiredException la manipulation sur le JSF/PrimeFaces requête ajax

---

sans rapport avec pour le problème concret, L'utilisation de HTTP POST pour une navigation pure page-à-page n'est pas très conviviale/SEO. Dans JSF 2.0, vous devriez vraiment préférer <h:link> ou <h:button> à la <h:commandXxx> ceux pour la navigation simple de page en page.

donc au lieu de par ex.

<h:form id="menu">
    <h:commandLink value="Foo" action="foo?faces-redirect=true" />
    <h:commandLink value="Bar" action="bar?faces-redirect=true" />
    <h:commandLink value="Baz" action="baz?faces-redirect=true" />
</h:form>

mieux faire

<h:link value="Foo" outcome="foo" />
<h:link value="Bar" outcome="bar" />
<h:link value="Baz" outcome="baz" />

Voir aussi

• Quand dois-je utiliser h:outputLink au lieu de H:commandLink?
• différence entre h: button et h: commandButton
• comment naviguer dans JSF? Comment faire URL refléter la page actuelle (et pas précédente)