通常、ConfigureListener
は、Mojarra実装JARファイルのファイルによって自動的に登録されます。さらに、ConfigureListener
はServlet 3.0 ServletContainerInitializer
で明示的に登録されているため、古いGlassFish v3バグを回避することができます(v3、3.0.xではなく、実際には最初のGF3バージョンです)。
.tld
ファイルによる自動登録が不十分な状況があります。よく知られているのは、webappがJettyに展開されたときです。これはこのQ & A:could not find Factory: javax.faces.context.FacesContextFactoryで詳細に説明されています。
さらに、GlassFish v3には、TLDファイルのスキャンが遅すぎるため、JSFが必要な初期化作業を適切なタイミングで実行できないというバグがあります。その後、ConfigureListener
をwebappのweb.xml
に明示的に登録する必要があります。
明示的にweb.xml
に登録されていないときに機能する場合は、そのまま使用してください。 web.xml
のノイズが少なくなります。しかし、上記の問題に敏感なコンテナに展開する可能性がある場合(つまり、Webアプリケーションが実際に公開されていて、ターゲットコンテナの選択を制御できない場合)、その場合は "それ"。
更新:このリスナーは、実際には2回の代わりに一度だけの実行されます:Tomcat 8.xのは、このエントリはweb.xml
で有効になっているとき、バグの挙動を示していることが表示されます。結果は悲惨です。とりわけ、すべてのJSFイベント・リスナーは2回登録され、コンポーネント・ライブラリーは2回ロードされます。これにより、実行時に競合が発生します。つまり、Tomcatにデプロイするときは、このエントリがweb.xml
から削除されていることを確認してください。
こちらをご覧くださいhttp://www.coderanch.com/t/428264/JSF/java/function-listener-sun-faces-config – Willmore