@ViewScoped fordert @PostConstruct bei jedem postback-Anfrage

In anderen Worten, Ihre @ViewScoped bean verhält sich wie ein @RequestScoped bean. Es wurde von Grund auf neu erstellt bei jedem postback-Anfrage. Es gibt viele mögliche Ursachen für diese, von denen die meisten darauf hinauslaufen, dass die damit verbundenen JSF-view nicht mehr verfügbar ist in der JSF-Staat, der wiederum ist standardmäßig im Zusammenhang mit der HTTP-Sitzung.

Vorausgesetzt, Sie können sicherstellen, dass der HTTP-Sitzung selbst ist nicht die Ursache des Problems ist, D. H. wenn @SessionScoped arbeitet absolut fein, dann gehen Sie durch die unten stehende Liste der möglichen Ursachen. Andernfalls, wenn die HTTP-Sitzung selbst ist auch im Arsch und neu auf jede einzelne Anfrage, dann müssen Sie einen Schritt zurück und betrachten Sie als session-cookie und server-Konfiguration. Jede Ursache auf eine fehlerhafte HTTP-Sitzung ist mindestens jenseits der Kontext von JSF.

1. Bist du mit Mojarra 2.1.17 oder älter, und die Ansicht enthält EL-Ausdrücke, die binden, ein Blick scoped bean-Eigenschaft an ein tag-Attribut ausgewertet wird, während anzeigen erstellen. Beispiele sind JSTL <c:if>, <c:forEach> usw oder JSF <ui:include>, <x:someComponent id="#{...}", <x:someComponent binding="#{...}"> usw. Dies ist verursacht durch einen Fehler in Mojarra (Ausgabe 1492). Siehe auch Warum hat @PostConstruct-callback-Feuer jedes mal, obwohl bean @ViewScoped? JSF

   Dies ist schon fest in Mojarra version 2.1.18 Vorhandensein. Wenn Sie nicht aktualisieren Sie auf eine neuere version, ist die Problemumgehung zu deaktivieren partiellen Status speichern, wie unten in web.xml finden Sie auch JSTL in Facelets-JSF2... macht das Sinn?

   <context-param>
       <param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
       <param-value>false</param-value>
   </context-param>

   Oder, wenn Sie wollen, um einen bestimmten Satz von JSF-views nur:

   <context-param>
       <param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
       <param-value>/foo.xhtml;/bar.xhtml;/folder/baz.xhtml</param-value>
   </context-param>

   Wichtig zu erwähnen ist, dass die Bindung der Wert des JSF-Komponente id oder binding - Attribut auf einen Blick scoped bean-Eigenschaft ist eine schlechte Praxis. Diejenigen sollten sich wirklich an einen request scoped bean-Eigenschaft, oder eine alternative gesucht werden sollte. Siehe auch Wie funktioniert das 'binding' - Attribut arbeiten in JSF? Wann und wie sollten Sie eingesetzt werden?

2. Bist du mit Mojarra 2.2.0, nur diese version hat einen (noch unbekannten) Fehler bei der Aufrechterhaltung der Ansicht, der Umfang ist schon fest in 2.2.1, siehe auch Problem 2912. Lösung aktualisieren Sie auf eine neuere version.

3. Den @ViewScoped annotation importiert aus dem falschen Paket. JSF bietet zwei @ViewScoped Anmerkungen, einer aus javax.faces.bean - Paket für JSF managed beans kommentiert mit @ManagedBean, und noch einer aus javax.faces.view - Paket für CDI managed beans kommentiert mit @Named. Wenn die bean-scope annotation entspricht nicht den bean-management-annotation, die dann die eigentliche bean-scope werden die bean-management-framework die Standard-Rahmen, die @RequestScoped im JSF managed beans und @Dependent im CDI managed beans.

   Müssen Sie sicherstellen, dass Sie haben eine der folgenden Konstrukte und nicht mischen, siehe auch @ViewScoped bean neu erstellt bei jedem postback-request bei der Verwendung von JSF 2.2.

   import javax.faces.bean.ManagedBean;
   import javax.faces.bean.ViewScoped;
   
   @ManagedBean
   @ViewScoped
   public class CorrectJSFViewScopedBean implements Serializable {

   import javax.inject.Named;
   import javax.faces.view.ViewScoped;
   
   @Named
   @ViewScoped
   public class CorrectCDIViewScopedBean implements Serializable {

4. Ansicht ist (versehentlich?) markiert transient über <f:view transient="true">. Dieser dreht sich im Grunde auf "stateless JSF", die ist neu seit Mojarra 2.1.19. Hiermit die JSF-view einfach nicht gespeichert werden in der JSF-Zustand und die logische Konsequenz ist, dass alle referenzierten anzeigen scoped beans können nicht im Zusammenhang mit der JSF-view nicht mehr. Siehe auch Was ist der nutzen von Staatenlosigkeit in JSF?

5. Die web-Anwendung so konfiguriert ist, mit com.sun.faces.enableRestoreView11Compatibility context-param-set zu true in einen falschen versuchen zu "vermeiden" ViewExpiredException. Mit diesem context-param, die ViewExpiredException wird nie geworfen, aber die Aussicht (und alle assoziierten view-scoped beans) wird gerade von Grund auf neu erstellt. Allerdings, wenn das passiert, bei jeder Anfrage, dann ist dieser Ansatz tatsächlich verbirgt sich ein weiteres problem: die Ansichten verfallen viel zu schnell. Diese zeigt ein mögliches problem in der Aufrechterhaltung der JSF-view-Mitgliedstaaten und/oder die HTTP-Sitzung. Wie zu lösen/zu konfigurieren, richtig, den Kopf zu javax.Gesichter.- Anwendung.ViewExpiredException: Ansicht konnte nicht wiederhergestellt werden.

6. Web-Anwendung runtime classpath ist verschmutzt mit mehreren verschiedenen versionierten JSF-API und impl verwandten Klassen. Dies bewirkt, dass eine Beschädigung/mismatch in die Bezeichner,/Marker, die für die JSF-view state. Sie müssen sicherstellen, dass Sie nicht über mehrere JSF-API-JAR-Dateien in der webapp ist /WEB-INF/lib. Falls Sie mit Maven, stellen Sie gezielt sicher, dass Sie markieren Sie server-vorausgesetzt, die Bibliotheken als <scope>provided</scope>. Siehe auch "Installation JSF" Abschnitt in unsere JSF-wiki-Seite und die Antwort auf diese Frage: Wie man richtig installieren und konfigurieren Sie die JSF-Bibliotheken über Maven?.

7. Wenn Sie mit PrimeFaces <p:dialog>, dann stellen Sie sicher, dass die <p:dialog> hat seine eigene <h:form> und dass es nicht in einem anderen verschachtelten <h:form>. Siehe auch p:fileUpload-innen p:dialog verlieren @ViewScoped Werte.

8. Wenn Sie die Kombination von PrimeFaces FileUploadFilter mit PrettyFaces, dann stellen Sie sicher, dass die FileUploadFilter läuft auch auf PrettyFaces-umgeschrieben/weitergeleitet Anfragen. Siehe auch ViewScoped bean neu erstellt, wenn FileUploadListener nannte, mit PrettyFaces und Wie zu verwenden PrimeFaces p:fileUpload? Listener-Methode wird nie aufgerufen oder UploadedFile ist null, /wirft einen Fehler /nicht verwendbar.

9. Wenn Sie mit PrettyFaces, eine schlecht konfigurierte rewrite-Regel leitet die CSS/JS/Bild Ressourcen, um eine JSF-Seite mit einer @ViewScoped bean wird auch irreführende Verhalten. Siehe auch CDI ViewScope & PrettyFaces: Mehrere Anrufe zu @PostConstruct (JSF 2.2).

InformationsquelleAutor BalusC