問題タブ [application-client]

問題

アプリケーション クライアントのクラスに @EJB プロキシを挿入し、Mainその EJB にユーザーが特定のロールにいることを要求するメソッドがある場合、アプリケーション クライアント コンテナー (ACC) は、ユーザーがログインするとすぐにログインすることを要求します。アプリケーション クライアントが起動します。ACC は、クライアントが呼び出すことを念頭に置いていたメソッドを区別しないため、クライアントが実際に必要な役割 (存在する場合) は何であるかを区別しません。 EJB の 1 つのメソッドだけが、特定のロールを必要とするメソッドを持っています。EJB に で明示的に注釈を付けるかどうかは問題ではありません@PermitAll。ACC は引き続きユーザー名とパスワードの入力を求めます。指定されていない場合、GlassFish 3.1.2.2 (ビルド 5) の実装はすべてを中止し、"ユーザーが認証をキャンセルしました".

テスト環境を整えましょう！

次のようにリモート インターフェイスを宣言します。

EJB を記述します (私の問題はシングルトンに関連しているため、ここではあえて別のセッション アノテーションを使用しません!):

クライアント部分に関しては、私が考えることができる最小の実装は次のとおりです。

結果

クライアントがメソッドに対して "匿名" 呼び出しを正常に行ったと思いますechoGuestか? いいえ。私は、ACC@EJBが注入される前であっても、クライアントにユーザー名とパスワードの提供を強制することを発見しました。簡単に言えば、アプリケーション クライアントから EJB へのアクセス認証を混在させることはできません。上記の解決策は、メソッド@RolesAllowed("admin")から注釈を削除することです。echoAdmin

ある意味では、それは完全に理にかなっています。MainACC は、クライアントの起動中にのみアクティブになります。これが、注入されたすべてのリソースをクラス内のアプリケーション クライアントに配置し、それらstaticも作成する必要があるまさにその理由です。ACC は、EJB のどのメソッドが呼び出されるかどうかを正確に知ることはできません。

@PermitAllわかりましたが、それはおよび@RolesAllowedアノテーションの仕様と期待される動作を壊していませんか? アプリケーションクライアントに、特定のロールを必要とする、廃止され、呼び出されたことのないメソッドが 1 つしかない EJB への匿名アクセス権を提供する方法は、地球上にないのでしょうか? 今のところ、これらのメソッドを分離する必要があるのは、私が可能であり、実行すべきであると考えていたアノテーションを使用するだけでなく、EJB を完全に分離するためにロジックをリファクタリングする必要もあります。難しい感じ:'(

問題

Java Web Start で起動し、GlassFish 3.1.2.2 (ビルド 5) サーバーから起動したアプリケーション クライアントにエンタープライズ Java Bean を注入する@EJB..要件が満たされている限り動作します [下部の注を参照]。しかし、 を使用して何かを注入する@Injectと、注入しようとしているリソースの種類が何であれ、すべて失敗します。NullPointerException注入されたリソースを使用しようとすると、エラーが発生するため、失敗したことはわかっています。これは、注釈プロセッサが を完全に忘れていることを示してい@Injectます。

@EJB完璧に動作するのにまったく動作しないことに興味をそそられるだけでなく@Inject、このインジェクションの「サイレント エラー」はJava EE 6 仕様に違反しているに違いないと考えます。仕様書の 69 ページには次のように記載されています。

コンテナーが注入に必要なリソースを見つけられない場合、クラスの初期化は失敗し、クラスはサービスに入れられません。

この問題は、GlassFishのバグに関連しているか、バグの表現である可能性があります。

私の最終目標..

.. API を実装から分離することで、パフォーマンス テストやアプリケーションのプロファイリングを行うときに、さまざまな実装を試す作業がはるかに簡単になります。しかし、この設計パターンをアプリケーション クライアントで再現することはほとんど不可能だと思いますか? 私の当面のアプローチは、クラス内のすべての実装の新しいインスタンスを作成するMainか、ファクトリを使用することです。もちろん、最善の解決策は修飾子を使用することです!

注: アプリケーション クライアントでのインジェクションの要件は、コンポーネントに対して CDI を有効にする必要があることです (パッケージにはファイルbeans.xmlが含まれている必要があります。注釈に慣れている場合は、ほとんどの場合空です!)。アプリケーション クライアントでの CDI のサポートは、実際にはオプションです。実装固有。さらに、CDI が有効でサポートされている場合、アプリケーション クライアント コンテナはクライアントの起動中にのみアクティブにできるため、リソースをクラスに注入する必要がありMain、フィールドがstatic.

私は Java EE を適切に学習しようとしていますが、問題に直面しています。EE アプリケーションでクライアントを動作させることができません。以前にこの質問をして周りを見回したところ、mainEE 機能を使用してメソッドを実行する必要がある場合は、アプリケーション クライアント コンテナーが必要であることがわかりました。

私が試しているクライアントコードは

weblogic 12c のアプリケーション クライアント コンテナを介してこのクライアントを実行するにはどうすればよいですか?

Glassfish Java EE 7チュートリアルの「カートセキュア」の例で遊んでいるときに、「プログラムによるログイン」を試みました。

「CartClient」では、プログラムによるログインを簡単に行うことができます (コンストラクターなど)。しかし問題は、通常のコールバック ログイン メカニズムが最初に実行され、対話型の認証が成功した後にのみ、プログラムによるログインが有効になることです。

問題は、インジェクションがコールバック ログイン スキームを呼び出す前に、アプリケーション クライアントでプログラムによるログインを行う方法です。

タイトルが示すように、Application Server Application-Client の目的は何ですか?

Web を精査しても、Application Server の Application Client とは何か、その目的は何なのかについての説明はあまりありません。

私が収集できる情報から、アプリケーションクライアントは、アプリケーションサーバーでホストされているアプリケーションにアクセスするという点でブラウザーに似ていますが、アプリケーションクライアントはより優れた (グラフィカルな?) 対話性を提供しますか? また、アプリケーション サーバーのリソースまたは Java EE リソースへのアクセスを許可するコンテナーを作成しますか?

しかし、それがどのように組み合わされているのか、それが正確に何であるかはまだよくわかりません。