2010-08-09 5 views
1

Dans un ViewHandlerWrapper la mise en œuvre, j'ai le code suivant:HttpSession dans Manipuler un JSF ViewHandlerWrapper ne fonctionne pas

public void renderView(FacesContext context, UIViewRoot viewToRender) throws IOException, FacesException { 
    final String token = UUID.randomUUID().toString(); 

    HttpSession httpSession = (HttpSession) context.getExternalContext().getSession(true); 
    httpSession.setAttribute("expectedToken", token); 

    getWrapped().renderView(context, viewToRender); 
} 

Comme vous pouvez le voir, je veux ajouter un UUID à la session. Après le débogueur, je peux voir que l'attribut reste sur la session jusqu'à ce que le cycle complet de demande-réponse du conteneur de servlet soit terminé. Cependant, lors de l'invocation suivante, l'attribut "expectedToken" est nul. Avant d'aller "old school" (aller chercher la HttpSession) j'ai essayé de manipuler un objet de valeur sur la session, ce qui a rendu le même résultat. Le changement a été rejeté.

Est-ce pas censé fonctionner (après tout, la réponse n'est pas validée quand renderView est invoqué)?

Répondre

1

utiliser plutôt le JSF fourni ExternalContext#getSessionMap(). Ceci est à son tour soutenu de manière transparente par la session HTTP.

ExternalContext externalContext = FacesContext.getCurrentInstance().getExternalContext(); 
externalContext.getSessionMap().put("key", "value"); 

Un indice pour l'avenir, chaque fois que vous devez transporter l'API Servlet brut sous les hottes JSF, demandez-vous deux fois: Est-ce que je fais ce dans le bon sens? N'y a-t-il pas une manière JSF-ish? Dans presque tous les cas, il y a. Si en vain, il suffit de demander ici :)

+0

Eh bien, comme je l'ai dit "avant d'aller à l'ancienne", je l'ai essayé le JSF-way ... Ce qui n'a pas fonctionné :( – SiCN

+0

Apparemment, la session n'a pas été maintenue pour la demande suivante. beaucoup de causes, l'important étant: 1) le domaine a changé, 2) le contexte a changé, 3) le client ne supporte pas les cookies, 4) la session a été invalidée par programmation. – BalusC

+0

Il s'avère que toutes les versions présentées ici et que j'ai testées auparavant étaient OK et travaillées. Le problème est que je lis les valeurs de session au mauvais moment, ce qui rend toujours "NULL" comme résultat. Apparemment, il doit être lu avant RENDER_RESPONSE et après UPDATE_MODEL_VALUES. Je vais accepter les deux réponses parce que vous m'avez fait confiance que ce n'est pas mal d'ajouter quelque chose à la session dans un ViewHandler. – SiCN

2

Essayez d'obtenir la session sans loisirs

HttpSession httpSession = (HttpSession) context.getExternalContext().getSession(false); 
+0

Dommage mais cela n'a pas fait l'affaire. :/ – SiCN

Questions connexes