これは正しくないようです。コードのクリーンアップを行っていたところ、これに気づきました。すべての ajax リクエストは、コンストラクターと@PostConstruct
私の@ViewScoped
Bean を起動しています。単純なデータベースのページネーションでさえ、それを引き起こしています。
それはより長く、リクエストごとに再構築すべきではないことを理解しました。GET による完全なページのリロード後のみ。@ViewScoped
@RequestScoped
これは正しくないようです。コードのクリーンアップを行っていたところ、これに気づきました。すべての ajax リクエストは、コンストラクターと@PostConstruct
私の@ViewScoped
Bean を起動しています。単純なデータベースのページネーションでさえ、それを引き起こしています。
それはより長く、リクエストごとに再構築すべきではないことを理解しました。GET による完全なページのリロード後のみ。@ViewScoped
@RequestScoped
つまり、@ViewScoped
Bean は Bean のように動作し@RequestScoped
ます。ポストバック要求ごとにゼロから再作成されています。これには多くの原因が考えられますが、そのほとんどは、デフォルトで HTTP セッションに関連付けられている JSF 状態で、関連付けられた JSF ビューが使用できなくなっていることを要約します。
HTTP セッション自体が問題の根本原因ではないことを確認できる場合 (つまり、問題なく@SessionScoped
動作している場合) は、以下の考えられる原因のリストを確認してください。それ以外の場合、HTTP セッション自体もすべてのリクエストで破棄され、再作成される場合は、一歩下がってセッション Cookie とサーバー構成を確認する必要があります。壊れた HTTP セッションに関連する原因は、少なくとも JSF のコンテキストを超えています。
Mojarra 2.1.17 以前を使用しており、ビュー スコープ Bean プロパティをビュー ビルド時に評価されるタグ属性にバインドする EL 式がビューに含まれています。例としては JSTL <c:if>
、<c:forEach>
など、または JSF <ui:include>
、<x:someComponent id="#{...}"
、<x:someComponent binding="#{...}">
などがあります。これは Mojarra のバグが原因です (問題 1496 )。Bean が @ViewScoped であるにもかかわらず、@PostConstruct コールバックが毎回起動するのはなぜですか?も参照してください。JSF
これは Mojarra バージョン 2.1.18 ですでに修正されています。新しいバージョンにアップグレードできない場合の回避策は、以下のように部分的な状態の保存を無効にすることです。JSF2 Facelets の JSTLweb.xml
も参照してください...意味がありますか?
<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
<param-value>false</param-value>
</context-param>
または、特定の JSF ビューのセットのみをターゲットにする場合は、次のようにします。
<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>
重要なのは、JSF コンポーネントid
またはbinding
属性の値をビュー スコープの Bean プロパティにバインドすることは、悪い習慣であるということです。これらは実際にはリクエスト スコープの Bean プロパティにバインドする必要があります。または、代替手段を探す必要があります。「バインディング」属性は JSF でどのように機能しますか?も参照してください。いつ、どのように使用する必要がありますか?
Mojarra 2.2.0 を使用していますが、2.2.1 で既に修正されているビュー スコープの維持に (まだ不明な) バグがあるのはそのバージョンだけです。 issue 2916も参照してください。解決策は、新しいバージョンにアップグレードすることです。
@ViewScoped
注釈が間違ったパッケージからインポートされています。JSF は 2 つの@ViewScoped
アノテーションを提供します。1 つは でアノテーションjavax.faces.bean
が付けられた JSF マネージド Bean のパッケージ@ManagedBean
からのもので、もう 1 つは でjavax.faces.view
アノテーションが付けられた CDI マネージド Bean のパッケージからのもの@Named
です。Bean スコープ アノテーションが Bean 管理アノテーションと一致しない場合、実際の Bean スコープは@RequestScoped
、JSF マネージド Bean および@Dependent
CDI マネージド Bean にある Bean 管理フレームワークのデフォルト スコープになります。
次の構成のいずれかがあり、それらが混在していないことを確認する必要があります。JSF 2.2 を使用している場合は、すべてのポストバック要求で @ViewScoped Bean が再作成されるも参照してください。
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 {
ビューは (誤って?) によって一時的にマークされて<f:view transient="true">
います。これは基本的に、Mojarra 2.1.19 以降の新しい「ステートレス JSF」を有効にします。これにより、JSF ビューは JSF 状態にまったく保存されなくなり、論理的な結果として、参照されたすべてのビュー スコープ Bean を JSF ビューに関連付けることができなくなります。JSF におけるステートレスの有用性についても参照してください。
Web アプリケーションは、誤った "回避" の試行でcom.sun.faces.enableRestoreView11Compatibility
context パラメータが に設定されて構成されています。このコンテキスト パラメータを使用すると、 がスローされることはありませんが、ビュー (および関連するすべてのビュー スコープ Bean) は最初から再作成されます。ただし、それがすべてのリクエストで発生する場合、このアプローチは実際には別の問題を隠します: ビューの有効期限が早すぎるということです。これは、JSF ビューの状態や HTTP セッションを維持する際に問題が発生する可能性があることを示しています。それを適切に解決/構成する方法は、javax.faces.application.ViewExpiredException: View could not be Restoreに進みます。true
ViewExpiredException
ViewExpiredException
Web アプリケーションのランタイム クラスパスが、バージョン管理された複数の異なる JSF API または impl 関連のクラスで汚染されています。これにより、JSF ビュー ステートの識別子/マーカーの破損/不一致が発生します。webapp の に複数の JSF API JAR ファイルがないことを確認する必要があります/WEB-INF/lib
。Maven を使用している場合は、サーバー提供のライブラリを としてマークしていることを慎重に確認してください<scope>provided</scope>
。JSF wiki ページの「JSF のインストール」セクションと、関連する質問への回答も参照してください: Maven を介して JSF ライブラリを正しくインストールおよび構成する方法 .
PrimeFaces を使用している場合は、 に独自の があり、別の にネストされていないこと<p:dialog>
を確認してください。p:dialog が @ViewScoped 値を失う 内の p:fileUploadも参照してください。<p:dialog>
<h:form>
<h:form>
PrimeFacesFileUploadFilter
と PrettyFacesを組み合わせる場合はFileUploadFilter
、PrettyFaces で書き換え/転送されたリクエストでも実行されることを確認してください。ViewScoped bean rebuilt when FileUploadListener called using PrettyFacesおよびHow to use PrimeFaces p:fileUpload?も参照してください。リスナー メソッドが呼び出されないか、UploadedFile が null / エラーをスローする / 使用できない。
PrettyFaces を使用している場合、CSS/JS/画像リソースを@ViewScoped
Bean に関連付けられた JSF ページにリダイレクトする不適切に構成された書き換えルールも、誤解を招く動作を引き起こします。CDI ViewScope & PrettyFaces: @PostConstruct (JSF 2.2) への複数の呼び出しも参照してください。