J'ai un @managedbean code> que je voudrais remplacer avec un
@ @ @RequestScoped code> haricot.
public Login() {
HttpSession session = (HttpSession) FacesContext.getCurrentInstance().getExternalContext().getSession(false);
if (session != null) {
session.invalidate();
}
}
4 Réponses :
Je pense que vous êtes soit BTW, une requête SPOPED Bean n'est pas requise pour être sérialisable. Probablement @stevetaylor mélangé-le avec des haricots scopés de session. P>
Oui, seulement @sesstionsCoped code> et
@ApplicationsCoped code> semble être sérialisé. J'ai essayé de fournir un SSCCE mais il semble que je suppose que la partie JAAS tout fonctionne comme prévu. Je vais vérifier ça!
Un petit exemple de travail .. (court, autonome, correct (compilable), exemple). Impossible de savoir avec Google: p
corrigé en supprimant l'invalidation de la session dans le constructeur. Je ne sais toujours pas pourquoi @ Managedbean travaille et @Namé ne le fait pas. P>
Depuis que la question a changé depuis que j'ai réalisé ce qui se passe vraiment (SSCCE FTW;)) et je ne peux pas supprimer cette question, j'ai voté pour la fermeture. Je vais accepter toute réponse qui explique pourquoi @named code> ne fonctionne pas tandis que
@managedbean code> fait.
J'ai eu le même problème. Commuté de @ManèdeBean (qui fonctionnait) à @NAMED qui n'a pas fonctionné. J'ai eu un fichier haricot.xml dans Web-Inf qui n'a pas résolu le problème comme la plupart des gens suggèrent. Vous pouvez ajouter @ Stataless avec @named pour le faire fonctionner pour des raisons pour des raisons pour lesquelles je ne sais pas! Si quelqu'un peut expliquer que j'aimerais l'entendre. P>
Quoi qu'il en soit, je suppose que le «vrai» moyen de faire le travail @namé est ceci: @Named fonctionnera si vous importez la bonne annotation @RequestScoped; du package Javax.Enterprise.Context. L'annotation @RequestScoped à partir du package Javax.Faces.bean n'est pas compatible avec l'annotation @NAMED. Si vous omettez la bonne @RequestScoped d'être à côté de @NAMed, le haricot tirera, mais il ne lira aucune propriété. P>
ps. J'utilise Glassfish donc je doute que c'est un problème JBoss. P>
Comme vous pouvez le voir dans mon Q, j'ai utilisé la bonne annotation @RequestScoped. C'est une source courante pour les erreurs, cependant.
Pour ceux qui se battent toujours avec la question, cela a travaillé pour moi (la raison pour laquelle est toujours obscur)
J'utilise GF4 avec des NetBeans. NetBeans a également une excellente tabcompletion dans les pages JSF qui ne se sont pas coiffées de manière cohérente avec les injections. J'ai testé (actuellement) uniquement la périmètre de demande, mais je suppose que tout est dans le paquet. P>
Voici toutes les combinaisons que j'ai utilisées et là des résultats (sur la solution) P>
import javax.faces.bean.RequestScoped; import javax.annotation.ManagedBean; //=> Injection ok - Tab Completion NOK import javax.enterprise.context.RequestScoped; import javax.inject.Named; //=> Injection nok - Tab Completion OK import javax.enterprise.context.RequestScoped; import javax.faces.bean.ManagedBean; //=> Injection nok - Tab Completion OK import javax.faces.bean.RequestScoped; import javax.faces.bean.ManagedBean; //=> Injection nok - Tab Completion OK import javax.enterprise.context.RequestScoped; import javax.annotation.ManagedBean; //=> Injection nok - Tab Completion NOK
Votre haricot doit mettre en œuvre
java.io.Sérialisable code>. Grâce à Balusc pour souligner que cela ne résoudra pas le problème. Néanmoins, il est nécessaire que le haricot participe à CDI.
@Stevetaylor Pourriez-vous fournir une documentation sur laquelle Serializable est nécessaire pour un haricot de participer à CDI? Presque tous les exemples de
@named code> +
@RequestScoped code> ne sont pas sérialisables. Merci!
Pour la demande de demande, il n'a pas besoin d'être sérialisable.
Je ne sais pas non plus pourquoi vous faites cela dans un haricot, semble être un filtre ou un auditeur de requête serait préférable pour les trucs de session.
@LightGuard bien qui faisait partie du tutoriel. Je ne comprends pas pourquoi les œuvres managées et nommées ne sont pas, mais sans l'invalidation de la session, tout fonctionne bien.