|
|
以下の節では、メタデータ アノテーションと依存性注入の概念について説明します。
Java EE アノテーションの使用により、標準の application.xml および web.xml デプロイメント記述子は省略可能になりました。Java EE プログラミング モデルでは、EJB、サーブレット、Web アプリケーション、JSP などの Web コンテナに対して JDK 5.0 アノテーション機能を採用しています。
アノテーションを使用すると、コンテナ内でのアプリケーション コンポーネントの動作、依存性注入の要求方法などを Java クラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ アプリケーションの以前のバージョン (J2EE 1.4 以前) で必要だったデプロイメント記述子に代わるものです。
アプリケーション コンポーネントでは、必要なものの定義にアノテーションを使用できます。アノテーションを使用すると、デプロイメント記述子を扱う必要がなくなります。アノテーションにより、アプリケーション コンポーネントの開発は簡略化されます。引き続きデプロイメント記述子により、アノテーションで定義した値をオーバーライドすることもできます。アノテーション使用の一例としては、依存性注入 (DI) を必要とするフィールドまたはメソッドの定義が挙げられます。アノテーションは、EJB やサーブレットのような、POJO (プレーンな従来型 Java オブジェクト) コンポーネント クラスに対して定義されます。
フィールドまたはメソッド上のアノテーションでは、「リソースの依存性注入」に記載のとおり、フィールドやメソッドが注入を必要とすることを宣言できます。また、クラス自体にアノテーションを適用することもできます。クラスレベルのアノテーションは、アプリケーション コンポーネントの環境内でエントリを宣言しますが、リソースの注入にはつながりません。むしろ、アプリケーション コンポーネントでは、JNDI またはコンポーネント コンテキスト ルックアップ メソッドを使用してエントリをルックアップすることが前提となっています。アノテーションをクラスに適用する際には、JNDI 名および環境エントリ タイプを明示的に指定する必要があります。
Java EE Deployment API [JSR88] を使用すると、開発者はデプロイメント記述子を調べることができます。たとえば、デプロイメント記述子のない EJB モジュールの場合を考えます。このモジュールには、アノテーションを使用する EJB として宣言されたクラスがあることが前提です。Session Helper のユーザは、引き続きモジュールをデプロイメント記述子がある場合と同様に扱えます。したがって、開発者はコンフィグレーション情報を修正でき、その情報はデプロイメント プランに書き出されます。デプロイメント中、このようなプランは尊重され、アノテーションからの情報をオーバーライドします。
WebLogic Server ユーティリティ appc (およびそれと同等の Ant wlappc と Appmerge) では、メタデータ アノテーションをサポートしています。appmerge および appc ユーティリティは、アプリケーションまたはモジュールを入力として取り、それらを処理して、それぞれ出力アプリケーションまたはモジュールとして生成します。-writeInferredDescriptors フラグと一緒に使用すると、出力アプリケーションまたはモジュールには、アノテーション情報と共にデプロイメント記述子が含まれます。また記述子では、出力アプリケーションまたはモジュールが直接デプロイされるのであれば、実行の必要なアノテーション処理はないため、metadata-complete 属性が true に設定されます。ただし、以前に処理されたアプリケーションまたはモジュールでこれらのツールが呼び出された場合、metadata-complete 属性が true に設定されていると、appmerge および appc がアノテーションの処理について制限を受けます。
そのような場合、.orig サフィックスによって、本来の記述子を保持する必要があります。出力アプリケーションに対してアノテーションの処理を再適用する場合、開発者は記述子を復元して、もう一度 -writeInferredDescriptors フラグを使用する必要があります。appmerge または appc が、標準のデプロイメント記述子の存在しないエンタープライズ アプリケーションで、-writeInferredDescriptors と共に使用されると、記述子が生成され、Java EE 仕様の推論ルールに基づき、書き出されます。
appc の使い方の詳細については、「weblogic.appc リファレンス」を参照してください。appmerge の使い方の詳細については、「weblogic.appmerge を使用したライブラリの結合」を参照してください。
デプロイされたモジュールは、update デプロイメント オペレーションを使用して更新できます。そのような更新において、デプロイメント記述子または更新されたクラスに変更があった場合、コンテナでは新しいデプロイメント記述子を処理する一方で、アノテーション情報を再度検討する必要があります。
コンテナでは、記述子フレームワークの 2 フェーズの更新メカニズムを使用して、現在の記述子と提案されている記述子の相違点を確認します。このメカニズムはまた、動的でないプロパティに変更があった場合も、コンテナにそれを通知します。その後、コンテナはそのような動的でない変更を、独自の特定的な方法によって処理します。コンテナでは、正しい参照との相違点を確実に発見するため、提案された記述子に対しアノテーション処理を実行する必要があります。
同様に、モジュールのクラスの一部は、更新処理中に更新可能です。これらのクラスがアノテーションを通じてコンフィグレーション情報に影響を与えることがあり得ると分かった場合、コンテナは変更が加えられることを回避します。
依存性注入 (DI) を使用することで、アプリケーション コンポーネントで外部リソースおよびコンフィグレーション パラメータに対する依存性をアノテーションを介して宣言できます。コンテナはこれらのアノテーションを読み込み、リソースまたは環境エントリをアプリケーション コンポーネントに注入します。依存性注入は、リソースのルックアップを javax インタフェースまたは JNDI API を使用して行うことに代わる、非常に簡単なプログラミング方法です。
アプリケーション コンポーネントのフィールドまたはメソッドには、@Resource アノテーションを付けることができます。コンテナは、必要に応じて環境エントリを解放し、注入フィールドまたはメソッドに使用されるプリミティブ型に一致させます。コード リスト 7-1 では、アプリケーション コンポーネントで @Resource アノテーションを使用して環境エントリを宣言する方法を示しています。
// フィールド
// デプロイヤによってコンフィグレーションされる、免税の最大件数
@Resource int maxExemptions;
// デプロイヤによってコンフィグレーションされる、免税の最小件数
@Resource int minExemptions;
…..
}
上記のコードでは、@Resource アノテーションは名前を指定していません。したがって、コンテナは <class-name>/maxExemptions という env-entry 名を探し、そのエントリの値を maxExemptions 変数に注入します。フィールドまたはメソッドには、任意のアクセス限定子 (public、private など) を指定できます。アプリケーション クライアントのメイン クラス以外のすべてのクラスについて、フィールドまたはメソッドは、静的なものとする必要があります。アプリケーション クライアントは、J2EE アプリケーションと同じライフサイクルを使用するため、アプリケーション クライアントのメイン クラスのインスタンスが、アプリケーション クライアントのコンテナによって作成されることはありません。その代わり、静的な main メソッドが呼び出されます。アプリケーション クライアントのメイン クラスに対する注入をサポートするため、注入用にアノテーションを付けられるフィールドまたはメソッドは静的であることが必要です。
アプリケーション コンポーネントでは、すべてのリソースが注入された後で、独自に初期化を実行する必要がある場合があります。このケースをサポートするため、クラスのメソッドの 1 つに、@PostConstruct アノテーションを付けることができます。このメソッドは、すべての注入が行なわれた後、クラスのサービスが開始される前に呼び出されます。このメソッドは、クラスが注入されるリソースを要求していなくても、呼び出されます。同様に、コンテナによってライフサイクルを管理されているクラスでは、クラスのサービスが終了し、これ以上はコンテナによって使用されなくなったときに呼び出される、1 つのメソッドに @PreDestroy アノテーションを適用できます。クラス階層構造内の各クラスに、@PostConstruct メソッドと @PreDestroy メソッドを指定できます。
メソッドの呼び出し順は、クラス階層構造における順序に一致しており、スーパークラスに対するメソッドが、サブクラスに対するメソッドよりも前に呼び出されます。Java EE 側からは、これらの Java EE クライアントのライフサイクル メソッドの呼び出しに関与しているのは、アプリケーション クライアント コンテナのみです。Java EE クライアントのライフサイクル メソッドは静的であることが必要です。Java EE クライアントは、@PostConstruct コールバックをサポートするのみです。
この節では、以下のアノテーションのリファレンス情報を提供します。
WebLogic Server エンタープライズ JavaBean に対する EJB 固有のアノテーションの詳細については、『WebLogic エンタープライズ JavaBeans バージョン 3.0 プログラマーズ ガイド』を参照してください。
WebLogic Server アプリケーションに対するコンポーネント固有のアノテーションの詳細については、『Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「Web コンポーネント用の WebLogic アノテーション」を参照してください。
依存性注入が完了した後、1 番目のビジネス メソッドを呼び出す前に、初期化を実行するためにアプリケーション コンポーネントから呼び出す必要のあるライフサイクル コールバック メソッドを指定します。このメソッドは、すべての注入が行なわれた後、クラスのサービスが開始される前に呼び出されます。このメソッドは、クラスが注入されるリソースを要求していなくても、呼び出されます。
依存性注入を含むすべてのコンポーネントには、@PostConstruct メソッドを指定する必要があります。
このアノテーションは、コンポーネント内の 1 つのメソッドにのみ付けることができます。
@PostConstruct アノテーションを付けるメソッドは、以下の要件を満たす必要があります。
javax.interceptor.InvocationContext オブジェクトを取ります。void でなければならない。public、protected、package private、または private にすることは可能。static であってはならない。final でも non-final でもよい。ただし、EJB の場合は non-final とする必要があります。PostConstruct アノテーションの付いたメソッドは、Bean インスタンスが破棄される前に例外およびクリーンアップを処理できます。
アプリケーション コンポーネントがコンテナによって破棄されようとしていることを通知するライフサイクル コールバック メソッドを指定します。通常、このアノテーションは、クラスが保持しているリソースを解放するメソッドに適用します。
このアノテーションは、Bean クラス内の 1 つのメソッドにのみ付けることができます。
@PreDestroy アノテーションを付けるメソッドは、以下の要件を満たす必要があります。
javax.interceptor.InvocationContext オブジェクトを取ります。void でなければならない。public、protected、package private、または private にすることは可能。static であってはならない。final でも non-final でもよい。ただし、EJB の場合は non-final とする必要があります。PreDestroy アノテーションの付いたメソッドは、Bean インスタンスが破棄される前に例外およびクリーンアップを処理できます。
外部リソース (JDBC データ ソース、JMS 送り先、接続ファクトリなど) への依存性を指定します。
このアノテーションをフィールドまたはメソッドに指定すると、Bean の初期化時に、要求されたリソースのインスタンスが Bean に注入されます。このアノテーションをクラスに適用すると、コンポーネントが実行時にルックアップするリソースが宣言されます。
@Resource アノテーションの配列を指定します。アノテーションの繰り返しは許可されていないため、Resources アノテーションは、複数のリソース宣言のコンテナとして機能します。
この節では、以下のアノテーションのリファレンス情報を提供します。
Java EE コンテナで使用されるセキュリティ ロールを定義します。
通常、このアノテーションは、アノテーションを付けたクラスのメソッド内から (たとえば isUserInRole メソッドを使用して) テストできるロールを定義するために使用します。また、クラスまたはクラスのメソッドで @RolesAllowed アノテーションを使用している場合はロールが暗黙的に宣言されますが、このアノテーションを使用することでそれらのロールを明示的に宣言できます。
セキュリティ ロールは、WebLogic Server で Administration Console を使用して作成できます。詳細については、「セキュリティ ロールの管理」を参照してください。
このアノテーションを付けたメソッドへのアクセスを、どのセキュリティ ロールにも許可しないことを指定します。つまり、このメソッドは、Java EE コンテナでの実行から除外されます。
このアノテーションを付けたメソッドへのアクセスを、WebLogic Server に定義されているすべてのセキュリティ ロールに許可することを指定します。
Java EE コンテナ内のメソッドにアクセスできるセキュリティ ロールのリストを指定します。
クラス レベルで指定した場合は、アプリケーション コンポーネント内のすべてのメソッドに適用されます。メソッド レベルで指定した場合は、そのメソッドにのみ適用されます。このアノテーションをクラス レベルとメソッド レベルの両方で指定した場合は、クラス レベルの値がメソッド レベルの値によってオーバーライドされます。
セキュリティ ロールは、WebLogic Server で Administration Console を使用して作成できます。詳細については、「セキュリティ ロールの管理」を参照してください。
Java EE コンテナを実際に実行するセキュリティ ロールを指定します。
指定するセキュリティ ロールは、WebLogic Server のセキュリティ レルム内に存在し、ユーザまたはグループにマッピングされている必要があります。詳細については、「セキュリティ ロールの管理」を参照してください。
|