JSF: Éviter les conflits de variables de portée de session lors du lancement de 2 instances d'une application

Question

J'ai une application JSF qui utilise beaucoup de variables de portée session. Une nouvelle exigence est que l'utilisateur devrait être capable d'ouvrir N numéros de l'application. Toutefois, étant donné qu'une grande partie de l'état a une portée de session, lorsque le client ouvre une seconde instance de l'application, les données de la première application sont saignées dans l'application nouvellement ouverte.

À ce stade, changeant tous les haricots scope à la session des haricots demander scope serait très difficile. Existe-t-il un moyen de résoudre ce problème à un niveau supérieur, en mappant peut-être des sessions externes (client) avec un ou plusieurs objets de session internes (artificiellement créés et utilisés par JSF)?

Answer 1

Vous pouvez contrôler la façon dont la session est fournie à l'application JSF via le FacesContextFactory (qui fournit le FacesContext qui contient le ExternalContext). Ceci doit être configuré dans un faces-config.xml afin que JSF puisse le détecter pendant l'initialisation. Si vous utilisez un constructeur de la forme MyFacesConfigFactory (FacesConfigFactory) JSF passera la fabrique précédemment configurée, vous permettant de décorer l'implémentation sous-jacente.

Certains problèmes que vous pouvez rencontrer:

• Vous auriez besoin d'un contrôle sur ce que signifie « ouvrir l'application » afin de créer une sous-session. Par exemple, un formulaire qui crée la sous-session.
• Vous avez besoin d'un mécanisme pour correspondre les demandes avec votre session - probablement à travers les méthodes de codage URL ExternalContext (qui devront être utilisés religieusement, utilisent déjà des composants bien comportés ces).
• Vous avez besoin d'une couche entière de code de gestion de session - je pense à des gens qui créent des sessions HTTP énormes juste en ouvrant plusieurs "instances" de l'application.
• Il y a probablement beaucoup de conditions de bord et d'autres choses auxquelles je n'ai pas pensé.

Ceci est une approche intéressante du problème, mais je ne m'attendrais pas à une solution rapide.

Answer 2

Il y a quelques cadres qui fixent ce problème pour vous, mais je ne suis pas sûr que l'adoption d'un nouveau cadre est une solution acceptable.

Seam offre le concept de champ en fonction de conversation, ce qui serait probablement faire ce que vous avez besoin de faire. Je sais aussi que le printemps a une portée équivalente.

Answer 3

Avez-vous vraiment besoin de travailler directement avec des objets de session? Pourquoi ne pas avoir une carte à portée de session, en mappant des identifiants de "sous-session" uniques à Maps pour les attributs de la sous-session? L'inconvénient est que vous devez inclure votre ID de sous-session sur chaque page en tant que paramètre caché inclus dans chaque requête client, et que tous vos EL pour les attributs de session doivent être quelque chose comme "# {subSession.mySubSessionId .myAttribute} ". Vous pouvez rencontrer d'autres problèmes, car une redirection ou une actualisation du navigateur peut détruire votre ID de sous-session.

Dans l'ensemble, je chercherais une solution de cadre. Il y a de meilleures chances qu'une solution d'infrastructure ait moins de bogues, et cela signifie également qu'il y a moins de code à créer et à maintenir. Il est beaucoup plus facile de se concentrer sur le développement d'applications réelles lorsque des détails de cette nature sont pris en charge pour vous.