web-dev-qa-db-ja.com

com.Sun.faces.config.ConfigureListenerの構成

web.xml構成に含まれている現在のJSFプロジェクトを確認しています。

  • facesServlet（*.xhtmlで構成）
  • com.Sun.faces.config.ConfigureListener

JSF2.2とMojarraの実装を使用しています。

ConfigureListenerについて混乱しています。このクラスは構成に必要ですか？このクラスの目標は何ですか？情報が見つからず、クラスにはjavadocがほとんどありません。

この構成を削除すると、すべてが同じように機能するように見えます。したがって、ConfigureListenerは削除できるか、削除する必要があると思いますが、よくわかりません。

jsfjsf-2mojarra
12
LaurentG

ConfigureListenerは通常、Mojarra実装JARファイルの/META-INF/jsf_core.tldファイルを介して自動的に登録されます。さらに、ConfigureListenerはサーブレット3.0ServletContainerInitializerを介して明示的に登録され、古いGlassFish v3のバグを回避します（注：3.0.xではなくv3であるため、実際にはこれまでで最初のGF3バージョンです） 。

.tldファイルによる自動登録が不十分な場合があります。よく知られているのは、webappが Jetty にデプロイされたときです。これについては、このQ＆Aで詳しく説明されています： ファクトリが見つかりませんでした：javax.faces.context.FacesContextFactory 。

また、前述のように、その詳細な回答で、GlassFish v3には、TLDファイルのスキャンが遅すぎるため、JSFが必要な初期化を適切なタイミングで実行できないというバグがあります。次に、ConfigureListenerをwebappのweb.xmlに明示的に登録する必要があります。

ただし、web.xmlに明示的に登録されていない場合に機能する場合は、使用しないでください。 web.xmlのノイズが少ないほど良いです。ただし、上記の問題の影響を受けやすいコンテナーにデプロイする可能性がある場合（つまり、Webアプリが実際に公開されているコンテナーであり、ターゲットコンテナーの選択を制御できない場合）、「それ"。

Update：このエントリがweb.xmlで有効になっている場合、Tomcat 8.xはバグのある動作を示すようです：このリスナーは実際には2回実行されます一度だけの。結果は悲惨です。とりわけ、すべてのJSFイベントリスナーが2回登録され、コンポーネントライブラリが2回ロードされます。これにより、実行時にのみ競合が発生します。つまり、Tomcatにデプロイするときは、このエントリがweb.xmlから削除されていることを確認してください。

14
BalusC