Random JSF Fehler: keine gespeicherten Ansichtszustand gefunden werden konnte

Ich habe einen sehr seltsamen Fehler: Keine gespeicherten Ansichtszustand gefunden werden konnte, der für die view-id: /mypage.xhtml

Das problem ist, dass es scheint, nach dem Zufallsprinzip, um nur ~10% der Nutzer/- Ausführungen.

Application server: Apache Tomee 1.5.2 stable /1.6.0-2013.09.20 dev (Es passiert auf beiden). Ich benutze MyFaces-distribution, die kommt mit jeden von Ihnen, so 2.1.10 /2.1.12, also nichts neues Hinzugefügt.

Teil web.xml:

      <context-param>
        <param-name>org.apache.myfaces.USE_ENCRYPTION</param-name>
        <param-value>false</param-value>
      </context-param>
      <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>client</param-value>
      </context-param>

So, keine Ansicht Status Ausnahme sollte nicht passieren, weil der Zustand ist auf den client. Es wurde auf dem server vor, aber ich dachte, vielleicht-client wird es zu beheben, aber nichts. Es war eigentlich kein Unterschied in dem auftreten des Fehler.

Ausführung Durchfluss:

1. Client öffnet xhtml-Seite (JSF).

2. Kunde klickt auf eine Schaltfläche Befehl, gewisse Dinge zu tun, Taster angeschlossen werden, um ein public void Methode einer JSF @ViewScoped ManagedBean.

3. Ja, die Methode ist void, weil ich nicht brauchen, um einen String zurückzugeben, der die Umleitung zu einer anderen Seite. Ich muss redirect /page/id (Beispiel: /Markt - /24, /Profil/43), also Methoden, die einen String zurückzugeben, der als Navigations-Ziele sind nutzlos, da benutze ich: FacesContext.getCurrentInstance().getExternalContext().redirect(path);

4. In ~90% der Fälle alles perfekt funktioniert und die Benutzer umgeleitet werden, um jede spezifische Seite. In den restlichen ~10 (zufällig), Sie bekommen No saved view state could be found for the view identifier: /pagename.xhtml

Ich würde wirklich zu schätzen einige helfen hier, denn ich habe keine Idee, wie das Problem behoben werden.

Vielen Dank im Voraus.

PS. Ich benutze PrimeFaces und ich habe auch ein paar eigene Filter in web.xml, aber das sollte nicht das problem sein, hoffe ich.

Stack-trace für eine der Seiten:

25-Sep-2013 07:39:26.380 SEVERE [http-bio-80-exec-15] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [Faces Servlet] in context with path [] threw exception [/dashboard/edit-profile.xhtmlNo saved view state could be found for the view identifier: /dashboard/edit-profile.xhtml] with root cause
 javax.faces.application.ViewExpiredException: /dashboard/edit-profile.xhtmlNo saved view state could be found for the view identifier: /dashboard/edit-profile.xhtml
        at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:132)
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:77)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:199)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at com.pingushare.boundary.filter.ActivateAccountFilter.doFilter(ActivateAccountFilter.java:37)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at com.pingushare.boundary.filter.SecurityFilter.doFilter(SecurityFilter.java:36)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at com.pingushare.boundary.filter.ForceFreshPageAndWWWFilter.doFilter(ForceFreshPageAndWWWFilter.java:49)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
        at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:724)

InformationsquelleAutor zmirc | 2013-09-24

0

Dieses Problem ist gut verstanden, und es geschieht, weil, wenn der server neu gestartet wird oder die Anwendung neu implementiert, ein neuer Schlüssel ist standardmäßig generiert. Die Lösung ist, erstellen Sie Ihre eigenen Schlüssel und legen Sie es in Ihrer web.xml Datei. So, MyFaces wird den gleichen Schlüssel verwenden, zu allen Zeiten. Sehen http://wiki.apache.org/myfaces/Secure_Your_Application

In der Beschreibung behauptet, dass die Verschlüsselung deaktiviert ist, und ich habe überprüft den code, und es ist ok, es funktioniert wie erwartet (die Verschlüsselung ist deaktiviert). Wenn die Verschlüsselung ist nicht das problem, meiner Meinung nach ist es ein Fehler in der Anwendungslogik. Rufen Sie nicht umgeleitet werden, verwenden Sie die standard form mit mypage.xhtml?faces-redirect=true . Das problem könnte verursacht werden durch einen Ablauf der Sitzung (beachten Sie, dass nur anzeigen, Umfang Bohnen geht, um die Kunden in 2.0/2.1, aber Gültigkeitsbereich einer session beans sind abgelaufen).
- Hi! Es ist nicht im Zusammenhang zu starten, da hast du auch erwähnt. Als ich erklärt habe, in meinem post, mypage.xhtml?faces-redirect=true " ist nicht nützlich für prettyfaces-URLs. Beispiel: wie stellen Sie die Umleitung auf: /mypage/ID1/ID2 mit, dass die Art und Weise, es zu tun? Zweitens, session-timeout ist auf 30 Tage in web.xml (302400). Der Fehler passiert zu zufälligen Zeiten für gelegentliche Nutzer, sondern alle Nutzer haben nicht mit dem system noch für 30 Tage, so ist es ein bisschen merkwürdig. Irgendwelche anderen Ideen?
- Wie kann man ein "Keine gespeicherten Ansichtszustand gefunden werden konnte, der für die view-id:" auf eine BEKOMMEN? Ich bin mir ziemlich sicher, dass es im Zusammenhang mit der Art und Weise, die Sie anrufen umleiten.
- Es geschieht nicht auf BEKOMMEN. Ich habe erwähnt die folgenden: Schritt 2: der Benutzer klickt auf einen Befehl btn, Schritt 3: btn angeschlossen ist eine Methode, Schritt 4: geht etwas schief, so dass die Methode nicht ausgeführt wird (weniger als 10~ der Fälle...sehr zufällig sowieso). Die Methode es ist nicht einmal erreicht, da dieses Kein Zustand Fehler.
- Aber der redirect ist eine BEKOMMEN, richtig? So, der code effektiv bricht die JSF-lifecycle. Es funktioniert nicht, weil das nicht sein soll, arbeiten.
- Ja, der redirect ist eine BEKOMMEN, aber das ist nicht der Fall, weil die command-button-Methode ist überhaupt nicht ausgeführt, so dass JSF nicht erreichen, dass Zeile code (redirect).
- ... Ich sehe. Ich fange an zu denken, die Umleitung Zeug sollte nicht das problem sein, und das problem ist, bevor Sie auf die Befehlsschaltfläche. Eine Möglichkeit ist, in irgendeinem Punkt, den view state beschädigt wird und der Algorithmus kann nicht die Wiederherstellung des Zustandes richtig. Versuchen Sie das aktivieren der Verschlüsselung und setzen Sie ein Geheimnis und eine mac-Geheimnis, wie beschrieben in die Seite. Wenn alles funktioniert, könnte es sein, dass die Verschlüsselung deaktivieren, stellen Sie einige Zeichen in den Staat. In diesem Fall einfach nur "ping" auf die Frage offen und ich check das nochmal.
- Ich werde versuchen, und kommen zurück mit feedback. Ich kann den Fehler reproduzieren, also muss ich noch ein wenig warten, in der Produktion, um zu sehen, ob es wieder passieren wird. Vielen Dank für die Hilfe.
- lassen Sie uns weiter, diese Diskussion im chat
- interessante Diskussion. können Sie aktualisieren Sie Ihren Beitrag mit PrimeFaces version und vielleicht 1 oder 2 xhtml (Befehlsschaltfläche/Link) - code-snippet? auch, verwenden Sie (oder haben Sie als Zugabe) OmniFaces (enableRestorableView) - Komponente, die speziell entwickelt wurde/umgesetzt-für viewExpiredException (für client-und server-Status speichern, denke ich). Ich habe es auf mein app, und ich benutze server-Status speichern, TomEE+ (neueste version, die meisten der Zeit), session-timeout von 30 Minuten. ich glaube nicht, dieses Problem auftreten. auch, wie viele Nutzer sind mit der app, wenn diese auftreten? erhalten Sie browser - (cache -) Einstellungen beim auftreten?
- oh, und ich bin nicht mit prettyfaces und ich nur tun, HttpResponse.redirect von http - /login-filter. Ich mache faces-redirect-string nur, wenn POST vom login.xhtml-index.xhtml.
InformationsquelleAutor lu4242
0

Nach langen Diskussionen auf MyFaces und Tomee Foren/mailing-Listen, das ist, wie ich es geschafft dieses problem zu beseitigen: ich geschaltet die JSF-Implementierung in diesem Projekt zu Majorra 2.1.26. Die Fehler erscheinen nicht mehr, bis jetzt.

Als dieser bug hat keinen Sinn (nach Prüfung der Quelle von meinem Projekt und MyFaces) und konnte nicht reproduziert werden, konnten wir nicht wirklich finden eine Lösung für Sie, aber zumindest ist es nicht geschehen, in Majorra, so könnte dies hilfreich sein, wenn jemand anderes kommt dieser Fehler.

Erwähnen: dies ist nicht die grundlegende "keine gespeicherten Ansichtszustand werden könnte, festgestellt," dass viele JSF-Entwickler. Das ist etwas, was irgendwo versteckt.

InformationsquelleAutor zmirc

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.