問題タブ [codi]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
0 に答える
213 参照

java - @ConversationGroupを統合するdeltaspike?

最近、余暇にデルタスパイクを試したりテストしたりしています。codi と seam 3 を統合したと書かれていますが、@conversationGroup が表示されないのはなぜですか?

手がかりはありますか?

ありがとう

0 投票する
1 に答える
1811 参照

websphere-liberty - Websphere Liberty Profile 8.5.5 で ejb ステートレスを使用する CODI

Web アプリケーションに @Stateless ejb が含まれている場合、Websphere Liberty Profile 8.5.5 に CODI を埋め込んだ Web アプリケーションを起動できません。

私はこの例外を受け取ります:

私は、プロジェクトに ejb が存在する場合にのみ問題が発生すると主張しました (私の場合は @Stateless ejb)。

この場合、アプリケーション コンテキストは、サーバーが起動され、webapp がインストール/デプロイされるときに初期化されます。ここでは問題ありません。

最初の HTTP 要求が webapp によって処理されると、FacesServletが初期化され、インスタンス化されCodiNavigationHandlerます。

メソッドCodiNavigationHandler.isAddViewConfigsAsNavigationCaseActivated()はコンストラクターで呼び出され、 CODI で参照を取得しようとしますJsfModuleConfig。これJsfModuleConfigには @ApplicationScoped アノテーションがあり、beanManager はアプリケーション コンテキストを取得しようとします。

このアプリケーション コンテキストは (webapp のデプロイ時に) 既に作成されていますが、LibertyContextsService.initApplicationContext(String)まだ呼び出されていません。そのため、アプリケーション コンテキストはLibertyContextsService.applicationContextsThreadLocal 変数で null になり、エラーが発生します。

再現するには:

  • 動的 Web プロジェクトを作成する
  • WEB-INF (単なるbeans要素)の下にほとんど空の beans.xml を追加します。
  • WEB-INF (単なるfaces-config要素)の下にほとんど空の faces-config.xml を追加します。
  • faces/index.xhtml で web.xml を追加します
  • WEB-INF/lib の codi jar をコピーします ( http://www.apache.org/dyn/closer.cgi/myfaces/binaries/myfaces-extcdi-assembly-jsf20-1.0.5-bin.zip )
  • ステートレス Bean を追加します。

    /li>
  • jsf Bean を追加します。

    /li>
  • 以下を使用して単純な jsf Web ページを追加します。

    /li>

注意: ejb の@statelessを削除すると、アプリケーションは動作します。

0 投票する
0 に答える
133 参照

jsf-2 - ClientSideWindowHandler を使用した Myfaces CODI - IE9 の戻るボタンの動作

私の JSF アプリで CDI と MyFaces CODI を使用している場合、次のようなリンクがあります。

リンクをクリックしてページ 2 に移動した後、IE9 で戻るボタンを押しても前のページに戻らず、ページ 2 を再レンダリングするだけです。ボタンを長押しすると、ページのリストが表示され、最後から 2 番目のページを選択できます。リストの一番上は、CODI のウィンドウ ハンドラーによって使用される "読み込み中..." ページです。

これは、MyFaces CODI が を使用するように構成されている場合に発生しますClientSideWindowHandler

Firefox と Chrome と IE11 は期待どおりに動作します (IE10 はテストされていません)。残念ながら、ほとんどのユーザーは IE9 になります。

ウィンドウスコープに CODI が提供する機能を使用しているため、ハンドラーなしでは実行できません。

これを回避する方法を知っている人はいますか?

0 投票する
1 に答える
2440 参照

java - Apache Tomcat 7 で MyFaces CODI + Weld + JSF をデプロイする際のエラー

私は JSF を初めて使用し、JSF が @ViewAccessScoped (CODI) のような便利な注釈を提供していないことに気付きました。CODI を使用するには、CDI 依存関係を使用する必要があるため、プロジェクトを Weld で構成しました。

次に、JSF + Weld + Tomcat 7 は正常に動作し、アノテーション スコープを Weld アノテーションに、@ManagedBean を @Named に、@NamedProperty を @Inject に変更します。

それ以外の場合、Tomcat サーバーを CODI でデプロイしようとすると、次のスタック トレース (@ViewAccessScoped アノテーションなどの CODI ライブラリを使用するかどうか) が表示され、サーバーがシャットダウンします。

非常に奇妙なエラー ログです。
主なポイントは、Tomcat 7 で JSF で CODI を使用するにはどうすればよいですか? CODIが提供するアノテーション @ViewAccessScoped を利用したい。
CODI は Weld と互換性がありますか? CODI がなければすべて正常に動作するため、これは非常に奇妙なスタック トレースです。

プロジェクトを JSF + CODI + Tomcat 7 でデプロイしようとすると、CODI が一部の CDI ライブラリで動作するため、エラーが発生することが予想されます (しかし、私のプロジェクトは CODI を使用しなくても動作します)。次に、再現されたスタックトレースの主要部分は次のとおりです。

私が使用しているライブラリは以下のとおりです。

TomEE を使用してみましたが、必要な唯一のライブラリはmyfaces-extcdi-bundle-jsf20-1.0.6.jarで、すべてが正常に機能した後です。

そうしないと、JSF v2.2+ を使用できません。TomEEで現在構成されている JSF のバージョンは 2.1です。タグにはバージョン 2.2+ でしかアクセスできないため、TomEE に移行したくありません。

0 投票する
1 に答える
177 参照

java - @Inject のステレオタイプは可能ですか?

私のアプリには、CDI プロデューサーによって作成されたオブジェクトを注入する繰り返しの注釈があります。

ステレオタイプ「@FlatGeometryLiveInject」を書くだけでいいのではないでしょうか

オブジェクトが注入されます。これは CDI 1.1 または任意の DI フレームワークで可能ですか?

0 投票する
0 に答える
109 参照

jsf - JSFパラメータの受け渡しでパラメータが時々nullになるのはなぜですか?

最初の Bean (myBean) のメソッドを呼び出せるように、使用するマネージド Bean (myBean) をパラメーターとして別のマネージド Bean (PersonRoleSearch) に渡します。ただし、パラメーターが null の場合があるため、nullpointer 例外が発生します。なぜそれが起こるのか、私には説明がありません。

Personrolesearch の init メソッドの階層です。

その理由は何ですか?

0 投票する
1 に答える
401 参照

jsf - ViewAccessScoped Bean が破棄されないのはなぜですか?

現在、作成したアプリケーションのメモリ リークを調査しています。ヒープ ダンプを分析した後、MyFaces CODI の奇妙な動作に焦点を合わせました。

ViewAccessScope を多用し、最近コードを修正して、対応するインスタンスのハッシュコードと共に @PostConstruct および @PreDestroy コールバックをログに記録しました。

PostConstruct コールバックは、たとえば、Bean を使用していないまったく別のビューから来た場合など、期待どおりに実行されます。@PreDestroy コールバックが呼び出されないことは、私を悩ませています (私は (私が思うに) 次のビューのどこにも Bean への参照がないことを確認しましたが)。

これをさらに混乱させているのは、それぞれが ViewAccesScoped Bean によってサポートされている 3 つのビューを持つ単純で小さなテスト プログラムを作成したという事実です。ビューを変更すると、移動元の Bean が、移動先のビューの Bean 内のどこにも参照されていないため、期待どおりに Bean が破棄されます。

したがって、私の質問は、ViewAccessScoped Bean のクリーンアップ/破棄動作に関して考慮すべき Bean 参照以外の要因はありますか?

JBoss AS Final 7.1.1 でバージョン 1.0.5 の MyFaces CODI を使用しています。