JSF - session tronqué bean partagé par les navigateurs sur différentes machines

Nous avons un formulaire de recherche où le filtre est lié à une propriété sur un bean géré (portée de session). Ce n'est pas une liaison de composant, sa propriété se liant comme <h:inputText value="#{searchBean.filter}"/>.JSF - session tronqué bean partagé par les navigateurs sur différentes machines

Les données soumises provenant de différentes machines (différentes sessions, alors) se mélangent. Vous recherchez "john", et obtenez "mary" juste parce que le gars à côté de vous vient de chercher "mary". La valeur de votre searchBean.filter obtient ses données soumises au lieu de la vôtre.

J'ai déjà beaucoup googlé et je n'ai trouvé aucune solution, juste une apparition du same problem.

Avez-vous déjà rencontré ce problème? Des indices?

Merci!

Source

2009-11-20 mcrisc

Utilisez-vous Spring (ou tout autre résolveur EL personnalisé)? – Bozho

Non. C'est simple JSF. J'utilise mojarra-1.2_13 avec 'javax.faces.STATE_SAVING_METHOD = client'. La seule chose que nous sommes obligés d'utiliser est [Infragistics NetAdvantage for JSF] (http://www.infragistics.com/java/netadvantage/jsf.aspx). – mcrisc

Copiez-vous une URL avec un 'jsessionid' intégré? Enregistrez-vous des écouteurs personnalisés? Avez-vous écrit des rendus personnalisés? – McDowell

Cela peut avoir deux causes:

Le haricot est en réalité une portée d'application. La propriété en question est déclarée static.

Pour corriger 1), assurez-vous simplement qu'il est dans la portée de session.
Pour corriger 2), supprimez simplement le modificateur illégal.

Source

2009-11-20 14:30:52 BalusC

Merci d'avoir répondu, Balus! Malheureusement, ni l'un ni l'autre n'arrive. Je viens de m'assurer que le bean est dans la portée de la session et que la propriété n'est pas statique. – mcrisc

S'agit-il réellement de deux machines physiquement différentes? Comment l'avez-vous testé? Le déclenchement de deux instances du même navigateur n'utilise pas différentes sessions. Le meilleur test consisterait alors à déclencher une instance de deux navigateurs différents chacun (par ex.un de IE et un de FF). Vous pouvez déboguer l'ID de session par '$ {pageContext.session.id}' dans la page. – BalusC

Aussi incroyable que cela puisse paraître, ce sont deux machines physiquement différentes, sur des tables différentes, avec des personnes différentes qui les utilisent. – mcrisc

Résolu! Enfin. Merci les gars, pour votre attention!

C'était quelque chose comme ce que Balus devinait la première fois. C'était un static caché dans un coin sombre. J'avais vraiment double, triple vérifié tout à la recherche de statique, mais - ne me demandez pas pourquoi - quelqu'un a créé un deuxième haricot (Foo) qui contenait une référence statique pour SearchBean. Dans la JSP, il y avait un action="#{foo.search}" au lieu de searchBean.search. La classe Foo avait une méthode avec le même nom que dans SearchBean, qui ne faisait pas plus de searchBean.search();.

Je pense que la pression pour corriger ce bug hier ne m'a pas permis de voir ce piège dans la JSP.

Source

2009-11-23 18:09:58 mcrisc

Content de l'avoir résolu. Les problèmes de sécurité des threads se résument toujours aux problèmes de portée (c'est-à-dire que l'application ou la session est incorrecte, ou simplement déclarée statique). C'est marrant qu'il y ait eu un conflit avec le code d'un autre. Peut-être été inachevé avec certains CVS? De toute façon, si la question est répondue, veuillez ne pas oublier de définir la réponse acceptée. – BalusC

JSF - session tronqué bean partagé par les navigateurs sur différentes machines

Répondre

Questions connexes