Java EE 6: Comment appeler un Bean de session avec État à partir d'un Bean de Session sans État?
J'ai un Bean de session avec état (SFSB) qui agit comme module d'authentification. Dans le SFSB, je stocke l'utilisateur actuel connecté. De plus, j'ai des façades (qui sont des Beans de session sans état (SLSB)) qui gèrent les trucs JPA/SQL pour mes entités. Afin de vérifier les autorisations d'accès de l'utilisateur actuel, j'essaie d'appeler le SFSB de la SLSB. Mais le champ utilisateur actuel est toujours "null" lorsqu'il est appelé depuis SLSB. Lorsque vous appelez directement le SFSB, le champ utilisateur actuel est défini correctement... Pour appeler, j'utilise l'annotation @EJB.
Des idées quel pourrait être le problème? Est-ce en quelque sorte un problème de contexte? Est-il généralement possible d'appeler un SFSB à partir de SLSB en préservant son état?
Un grand merci d'avance!
3 answers
Vous ne devez pas appeler un bean de session avec état à partir d'un bean de session sans état.
Voici quelques lectures: JEE6 Tutorial - Session Beans
Les beans sans état ne savent rien de votre session. Chaque fois que vous l'appelez, il est apatride. Ensuite, il appelle un bean de session avec état. Pas surprenant qu'il n'ait aucun contexte relatif à l'état de la session du client car il est appelé à partir d'un objet sans état.
Je ne sais pas si cela fonctionnera, mais vous pourriez peut-être essayer pour obtenir le contexte en faisant une recherche JNDI au lieu de DI en utilisant la notation @EJB. Quelque chose comme ça dans l'ejb sans état pourrait fonctionner. Vous devrez probablement jouer avec et je ne peux rien garantir. Il devrait obtenir le contexte du client appelant l'ejb sans état. Le client devra avoir le contexte/la portée de la session ou l'oublier.
@Resource SessionContext sessionContext;
MyStatefulBean msb = (MyStatefulBean)sessionContext.lookup("ejb/MyStatefulBean");
msb.doSomething(fubar);
Il est préférable d'appeler le bean de session avec état depuis un client qui a une portée de session ou depuis un autre ejb avec état. Apatride et avec état ont différentes raisons d'être.
Vous ne devez pas injecter un EJB avec état dans un EJB sans état. Cela peut avoir des conséquences très imprévisibles, car le cycle de vie d'un EJB avec état est démarré lorsqu'il est injecté et géré en possédant un bean. Dans le pire des cas, l'EJB sans état peut être réutilisé par le serveur d'applications pour différents utilisateurs, qui accéderaient alors au même EJB avec état. Dans votre cas, un utilisateur serait identifié comme un utilisateur différent.
Vous souhaitez probablement associer un EJB avec état à la session HTTP en cours, qui n'est pas fait automatiquement comme beaucoup de gens le supposent. Pour plus de détails, lisez la section nommée EJB 3 N'est Pas Contextuelle ici: Contexts and Dependency Injection article
Pour associer un EJB avec état à la session, vous devez injecter un EJB avec état dans un bean CDI à portée de session, qui peut être injecté librement dans un bean sans état - en fait, seul un stub est injecté et un bean à portée de session (avec l'EJB avec état) est créé pour chaque nouvelle session.
Peut-être même une meilleure approche consiste à extraire l'interface du bean avec état et à utiliser un producteur CDI pour créer une implémentation de portée de session du bean sateful. De cette façon, vous pouvez également gérer le cas, lorsqu'un EJB avec état est automatiquement supprimé sur une exception dans l'EJB. Dans ce cas, vous pouvez recréer l'EJB dans la même session.
Si vous injectez le bean de session avec état dans le bean sans état par recherche, cela ne fonctionne pas non plus car une nouvelle instance sera créée pour le bean avec état, de sorte qu'elle ne contient aucune valeur comme les informations utilisateur enregistrées, etc...