The Java EE 7 Tutorialの25 Contexts and Dependency Injection for Java EE: Advanced Topicsのセクションを読んでテキトーに訳した。
25 Contexts and Dependency Injection for Java EE: Advanced Topics
このチャプターではContexts and Dependency Injection for Java EE (CDI)のより高度な機能について解説します。とくに、CDIの高度な機能が提供する強い型付けによる疎結合コンポーネントに触れます。
以下のトピックをここで扱います。
- Packaging CDI Applications
- Using Alternatives in CDI Applications
- Using Producer Methods, Producer Fields, and Disposer Methods in CDI Applications
- Using Predefined Beans in CDI Applications
- Using Events in CDI Applications
- Using Interceptors in CDI Applications
- Using Decorators in CDI Applications
- Using Stereotypes in CDI Applications
25.1 Packaging CDI Applications
Java EEアプリケーションをデプロイするとき、CDIはbean archvies内のbeanを探索します。bean archiveは任意のモジュールで、このモジュールにはCDIランタイムがmanageおよび注入が可能なbeanが含まれています。bean archivesには二種類あり、explicit bean archivesとimplicit bean archivesです。
explicit bean archiveはbeans.xmlデプロイメント記述子を含むarchiveで、このファイルは空ファイルが可能で、version number無し、もしくはversion number 1.1でbean-discovery-mode属性にallと設定します。たとえば、
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" version="1.1" bean-discovery-mode="all"> ... </beans>
CDIは、explicit archiveでは@Vetoedアノテーション付与されたものを除いて、任意のbeanをmanageおよび注入可能です。
implicit bean archiveは、scope typeアノテーションを付与されたbeanを含み、beans.xmlデプロイメント記述子を含まないか、bean-discovery-mode属性にannotatedを設定したbeans.xmlデプロイメント記述子を含みます。
implicit archiveでは、CDIはscope typeアノテーションを付与されたbeanのみmanageと注入が可能です。
webアプリケーションでは、beans.xmlデプロイメント記述子はもし存在するなら、WEB-INFディレクトリに配置します。EJBモジュールやJARファイルでは、beans.xmlデプロイメント記述子はもし存在するなら、META-INFディレクトリに配置します。
25.2 Using Alternatives in CDI Applications
あるbeanが異なる目的に使用するために複数バージョンを持つ場合、The simplegreeting CDI Exampleで示すように、あるqualifierか別のqualifierかをデプロイメント時に注入することでbeanを選択することが出来ます。
アプリケーションのソースコードを変更する代わりに、デプロイ時にalternativesを使うことが出来ます。
Alternativesは以下のような目的に良く使用されます。
- 実行時に決定されるクライアント依存のビジネスロジックを扱うため。
- 特定のデプロイメントシナリオを検証するbeanを指定するため（たとえば、国ごとの消費税法が要求する国ごとの消費税ビジネスロジック）。
- テストに使用するbeanのダミー（モック）バージョンを作成するため。
beanをルックアップ、注入、EL解決で使用可能にするには、javax.enterprise.inject.Alternativeアノテーションを付与して、beans.xmlにalternatives要素を指定します。
例えば、beanの完全なバージョンと、テストのためだけの簡易バージョンを作成したいとします。The encoder Example: Using Alternativesで解説されているサンプルは二つのbeanCoderImplとTestCoderImplを持っています。テスト用のbeanは以下のアノテーションが付与されています。
@Alternative public class TestCoderImpl implements Coder { ... }
完全なバージョンにはアノテーションはありません。
public class CoderImpl implements Coder { ... }
managed beanはCoderインターフェースのインスタンスを注入します。
@Inject
Coder coder;
アプリケーションがbeanのalternativeバージョンを使うのは、beans.xmlファイルで下記のようにバージョンが宣言されている場合だけです。
<beans ...> <alternatives> <class>javaeetutorial.encoder.TestCoderImpl</class> </alternatives> </beans>
beans.xmlのalternatives要素をコメントアウトするとCoderImplクラスが使われます。
同一インタフェースを実装する複数のbeanすべてに@Alternativeアノテーションを付与可能です。この場合、使用するalternative beanを記述したbeans.xmlファイルを指定しなければなりません。もしCoderImplにも@Alternativeアノテーションが付与されている場合、二つのbeanの一つを常にbeans.xmlに指定する必要があります。
beans.xmlファイルで指定されるalternativesは同一archiveのクラスにのみ適用されます。複数モジュールで構成されるアプリケーションでグローバルなalternativesを指定するには@Priorityアノテーションを使用します。以下がその例です。
@Alternative @Priority(Interceptor.Priority.APPLICATION+10) public class TestCoderImpl implements Coder { ... }
もし@Priorityアノテーションを付与された同一インタフェースを実装する複数のalternative beansがある場合、高プライオリティ値のalternativeが選択されます。@Priorityアノテーションを使用する場合、beans.xmlでalternativeを指定する必要はありません。
25.2.1 Using Specialization
Specializationは、あるbeanを別のbeanで代替できるという点でalternativesと似た機能を持ちます。しかし、すべての場合で他のbeanをオーバーライドしたい場合もあるでしょう。例として下記二つのbeanを定義したとします。
@Default @Asynchronous public class AsynchronousService implements Service { ... }
@Alternative public class MockAsynchronousService extends AsynchronousService { ... }
このとき、beans.xmlでalternativeとしてMockAsynchronousServiceを宣言したとすると、以下の注入ポイントはMockAsynchronousServiceを解決します。
@Inject Service service;
しかし、以下はMockAsynchronousServiceではなくAsynchronousServiceを解決しますが、その理由はMockAsynchronousServiceは@Asynchronous qualifierを持たないからです。
@Inject @Asynchronous Service service;
MockAsynchronousServiceが常に注入されることを保証するには、すべてのbean typeとAsynchronousServiceのbean qualifiersを実装する必要があります。しかし、もしAsynchronousServiceがproducer methodやobserver methodを宣言した場合、この扱いづらいメカニズムは他のbeanが決して呼ばれないことを保証しません*1。Specializationはシンプルなメカニズムを提供します。
Specializationは、実行時および開発時に動作します。もしあるbeanが別のbeanをspecializesすると宣言する場合、そのbeanはその他のbeanクラスを拡張し、実行時にspecialized beanが別のbeanを完全に置き換えます。もし前者のbeanがproducer methodで生成される場合、producer methodもオーバーライドする必要があります。
beanをspecializeするにはjavax.enterprise.inject.Specializesアノテーションを付与します。たとえば、以下のようにbeanを宣言します。
@Specializes public class MockAsynchronousService extends AsynchronousService { ... }
この場合、MockAsynchronousServiceクラスがAsynchronousServiceの代わりに常に呼び出されます。
通常、@Specializesアノテーションが付与されたbeanはalternativeでありbeans.xmlでalternativeとして宣言されます。そうしたbeanはデフォルト実装を置き換えることを意味し、alternative実装は自動的にデフォルト実装の全qualifiersを継承します。もしEL名があればそれも継承します。
25.3 Using Producer Methods, Producer Fields, and Disposer Methods in CDI Applications
producer methodは注入可能なオブジェクトを生成します。一般的に、以下の場合にproducer methodsを使用します。
- そのbean自身ではないオブジェクトを注入するとき。
- 注入されるオブジェクトの実装型が実行時に変化するとき。
- beanのコンストラクタが実行しないカスタム初期化をオブジェクトが要求するとき。
producer methodsの詳細な情報についてはInjecting Objects by Using Producer Methodsを参照してください。
producer fieldはproducer methodのシンプルな別の方法で、オブジェクトを生成するbeanのフィールドです。単純なgetterメソッドの代わりに使用可能です。Producer fieldsは、データソース・JMSリソース・webサービス参照のようなJava EEリソースを宣言するのに役立ちます。
producer methodやfieldにはjavax.enterprise.inject.Producesアノテーションを付与します。
25.3.1 Using Producer Methods
producer methodによって、開発時とデプロイ時ではなく実行時にbean実装を選択可能になります。たとえば、The producermethods Example: Using a Producer Method to Choose a Bean Implementationでは、managed beanは以下のproducer methodを定義しています。
@Produces @Chosen @RequestScoped public Coder getCoder() { switch (coderType) { case TEST: return new TestCoderImpl(); case SHIFT: return new CoderImpl(); default: return null; } }
getCoderは実質的にはgetterメソッドで、メソッドと同じアノテーションとqualifierを付与することでcoderプロパティが注入され、インタフェースの選択したバージョンが使用されます。
@Inject @Chosen @RequestScoped Coder coder;
qualifierの指定は必須で、注入するCoderをCDIに伝えます。qualifier無しでは、CDI実装はCoderImpl, TestCoderImpl, getCoderが返すいずれかの型から一つを選ぶことが出来ず、曖昧な依存関係をユーザに知らせてデプロイをキャンセルします。
25.3.2 Using Producer Fields to Generate Resources
producer fieldのよくある使い方はJPAのEntityManager（Chapter 37, "Introduction to the Java Persistence API,"を参照）やJDBCDataSourceなどのオブジェクトを生成することです。こうしたオブジェクトはコンテナによってmanagedされます。たとえば、@UserDatabasequalifierを作成して以下のようにentity manager用のproducer fieldを宣言可能です。
@Produces @UserDatabase @PersistenceContext private EntityManager em;
@UserDatabasequalifierが使用可能な場所は、別のbeanにオブジェクトを注入するとき、RequestBean、アプリケーションのどこででもOKです。
@Inject @UserDatabase EntityManager em; ...
The producerfields Example: Using Producer Fields to Generate Resourcesのサンプルではproducer fieldsでentity managerを生成する方法を示しています。似たような@Resource, @EJB, @WebServiceRefオブジェクトを注入するメカニズムも使用可能です。
resource injectionへの依存を最小化するために、アプリケーションの一か所でリソース用のproducer fieldを指定し、それからアプリケーションの必要な場所にオブジェクトを注入してください。
25.3.3 Using a Disposer Method
producer methodやproducer fieldをオブジェクト生成に使用し、必要であれば実行後に削除することが出来ます。そのためには、@Disposesアノテーションを付与したdisposer methodが必要です。たとえば、以下のようにentity managerをクローズ可能です。
public void close(@Disposes @UserDatabase EntityManager em) { em.close(); }
disposer methodはcontextが終了するときに自動的に呼ばれ（この例の場合、RequestBeanがconversation scopeなのでconversationの終了時）、closeメソッドの引数はproducer fieldが生成したオブジェクトになります。
25.4 Using Predefined Beans in CDI Applications
Java EEは以下のインタフェースを実装する定義済みbeanを提供します。
javax.transaction.UserTransaction: A Java Transaction API (JTA)ユーザトランザクション。java.security.Principal: 個人・企業・ログインIDなどの任意のエンティティを表現するプリンシパルの抽象的な概念です。注入されたプリンシパルにアクセスが行われるときは常に、プリンシパルは現在の呼び出し元のアイデンティティを表現しています。たとえば、プリンシパルは初期化時にフィールドに注入されます。その後、注入されたプリンシパルを使用するメソッドは、プリンシパルが注入されたオブジェクト上で呼び出されます。この例では、注入されたプリンシパルはメソッドが実行されるときの現在の呼び出し元のアイデンティティを表現しています*2。javax.validation.Validator: beanインスタンス用のvalidator。このインタフェースを実装するbeanはdefault bean validation objectValidatorFactory用のValidatorオブジェクトを注入可能にします。javax.validation.ValidatorFactory: 初期化されたValidatorインスタンスを返すためのファクトリークラス。このインタフェースを実装するbeanはdefault bean validationValidatorFactoryobjectを注入可能にします。javax.servlet.http.HttpServletRequest: クライアントからのHTTPリクエスト。このインタフェースを実装するbeanによってservletでリクエストの詳細を取得可能になります。javax.servlet.http.HttpSession: クライアントとサーバ間のHTTPセッション。このインタフェースを実装するbeanによってservletでセッションに関する情報にアクセスし、セッションにオブジェクトをバインド可能になります。javax.servlet.ServletContext: servletsがサーバブレットコンテナで通信するためのコンテキストオブジェクト。
定義済みbeanを注入するには、リソースにはjavax.annotation.Resourceアノテーション、CDI beanにはjavax.inject.Injectアノテーションを使用して、beanのインスタンスを取得するための注入ポイントを作成します。bean typeごとに、beanが実装するインタフェースのクラス名を指定します。
Table 25-1 Injection of Predefined Beans
| Predefined Bean | Resource or CDI Bean | Injection Example |
|---|---|---|
| UserTransaction | Resource | @Resource UserTransaction transaction; |
| Principal | Resource | @Resource Principal principal; |
| Validator | Resource | @Resource Validator validator; |
| ValidatorFactory | Resource | @Resource ValidatorFactory factory; |
| HttpServletRequest | CDI bean | @Inject HttpServletRequest req; |
| HttpSession | CDI bean | @Inject HttpSession session; |
| ServletContext | CDI bean | @Inject ServletContext context; |
定義済みbeanは、dependentスコープおよび定義済みデフォルトqualifier@Defaultで注入されます。
注入されるリソースの詳細については、Resource Injectionを参照してください。
以下のコード片は定義済みbeanを注入するために@Resourceと@Injectアノテーションを使用する方法を示しています。このコードはユーザトランザクションとcontextオブジェクトをservletクラスTransactionServletに注入します。ユーザトランザクションはjavax.transaction.UserTransactionインタフェースを実装する定義済みbeanのインスタンスです。contextオブジェクトはjavax.servlet.ServletContextインタフェースを実装する定義済みbeanのインスタンスです。
import javax.annotation.Resource; import javax.inject.Inject; import javax.servlet.http.HttpServlet; import javax.transaction.UserTransaction; ... public class TransactionServlet extends HttpServlet { @Resource UserTransaction transaction; @Inject ServletContext context; ... }
25.5 Using Events in CDI Applications
イベントにより、コンパイル時の依存関係を必要としないbean間通信が可能になります。あるbeanがイベントを定義し、別のbeanがイベントを発火し、また別のbeanがイベントをハンドリングします。それぞれのbeanは別々のパッケージやアプリケーションの別階層で定義可能です。
25.5.1 Defining Events
イベントは以下の要素で構成されます。
- Javaオブジェクトのイベントオブジェクト。
- ゼロ個以上のevent qualifiers
例として、The billpayment Example: Using Events and InterceptorsサンプルのPaymentEventbeanは三つのプロパティとそのsetter/getterを持っています。
public String paymentType; public BigDecimal value; public Date datetime; public PaymentEvent() { }
また、このサンプルは二種類のPaymentEventを区別するqualifiersを定義しています。すべてのイベントはデフォルトのqualifier @Anyも持ちます。
25.5.2 Using Observer Methods to Handle Events
イベントハンドラはイベントを受け取るためにobserver methodを使用します。
各observer methodは、引数として@Observesアノテーションと任意のqualifiersを付与された特定のイベントタイプを取ります。observer methodは、もしイベントオブジェクトがイベントタイプにマッチするか、イベントの全qualifiersがobserver methodのevent qualifiersとマッチする場合、イベント通知を受けます。
observer methodはイベント引数に加えて他の引数を取ることが出来ます。追加引数は注入ポイントと宣言可能なqualifiersです。
billpaymentサンプルのイベントハンドラPaymentHandlerは二つのobserver methodsを定義し、PaymentEventの各タイプごとに一つのメソッドがあります。
public void creditPayment(@Observes @Credit PaymentEvent event) { ... } public void debitPayment(@Observes @Debit PaymentEvent event) { ... }
また、Observer methodsはconditionalかtransactionalにできます。
- conditional observer methodは、observer methodを定義するbeanインスタンスがすでに現在のコンテキストに存在する場合のみ、イベント通知を受けます。conditional observer methodを宣言するには、
@Observesの引数にnotifyObserver=IF_EXISTSを指定します。
@Observes(notifyObserver=IF_EXISTS)
デフォルトのunconditionalにするには、@Observes(notifyObserver=ALWAYS)を指定します。
- transactional observer methodは、イベントが発火したトランザクションの完了前(before-completion)や完了後(after-completion)フェーズに、イベント通知を受けます。トランザクションが正常か非正常に完了した後にのみ通知が発生するようにも指定できます。transactional observer methodを作成するには、
@Observesの引数に以下のいずれかを指定します。
@Observes(during=BEFORE_COMPLETION) @Observes(during=AFTER_COMPLETION) @Observes(during=AFTER_SUCCESS) @Observes(during=AFTER_FAILURE)
デフォルトのnontransactionalを使用するには、@Observes(during=IN_PROGRESS)を指定します。
トランザクション完了前に呼び出されるobserver methodは、トランザクションインスタンスにトランザクションロールバックを強制するために、setRollbackOnlyメソッドを呼び出すことができます。
Observer methodsは例外をスロー可能です。もしtransactional observer methodが例外をスローすると、例外はコンテナによって捕捉されます。もしobserver methodがnontransactionalなら、例外はイベント処理を強制終了させ、他のobserver methodsは一切呼び出されません。
25.5.3 Firing Events
イベントを発火するには、javax.enterprise.event.Event.fireメソッドを呼びます。このメソッドはイベントを発火して任意のobserver methodsに通知を行います。
billpaymentサンプルでは、managed beanのPaymentBeanはユーザインタフェースから受け取る情報を使用して適切なイベントを発火します。4つのbeanがあり、二つはイベントオブジェクトで、二つはデータ保持用です。managed beanは二つのイベントbeanを注入します。payメソッドは、データ保持用オブジェクトを生成するためにnewを使用し、発火するイベントを選択するためにswitchを使います。
@Inject @Credit Event<PaymentEvent> creditEvent; @Inject @Debit Event<PaymentEvent> debitEvent; private static final int DEBIT = 1; private static final int CREDIT = 2; private int paymentOption = DEBIT; ... @Logged public String pay() { ... switch (paymentOption) { case DEBIT: PaymentEvent debitPayload = new PaymentEvent(); // populate payload ... debitEvent.fire(debitPayload); break; case CREDIT: PaymentEvent creditPayload = new PaymentEvent(); // populate payload ... creditEvent.fire(creditPayload); break; default: logger.severe("Invalid payment option!"); } ... }
fireメソッドの引数はデータ保持用クラスのPaymentEventです。発火されたイベントは、observer methodsが受け取ります。
25.6 Using Interceptors in CDI Applications
interceptorは、関連付けられたターゲットクラスで発生するライフサイクルイベントもしくはメソッド実行を割り込むために使われるクラスです。インターセプターが実行するタスクは、ログや監査など、アプリケーションのビジネスロジックから切り離され、また、アプリケーション内で繰り返し出現するものです。そうしたタスクはしばしばcross-cuttingタスクと呼ばれます。インターセプターはメンテナンスが容易になるように一箇所でそうしたタスクのコードを指定します。Java EEプラットフォームに初めてインターセプターが導入されたときはEJBを指定していました。Java EE 7プラットフォームにおいては、managed beanを含む全種類のJava EE managed objectをインターセプターに指定可能です。
Java EEのインターセプターについての詳細な情報は、Chapter 54, "Using Java EE Interceptors"を参照してください。
インターセプターのクラスはたいてい@AroundInvokeアノテーションを付与されたメソッドを含み、インターセプトされるメソッドが実行されるときにインターセプターが実行するタスクを指定します。また、ライフサイクルコールバックインターセプターを指定するために@PostConstruct, @PreDestroy, @PrePassivate, @PostActivateアノテーションを付与したメソッドを含むことも出来、@AroundTimeoutでEJBタイムアウトインターセプターを指定することも出来ます。インターセプタークラスは一つ以上のインターセプターメソッドを含むことが出来ますが、各タイプに一つだけメソッドを作成しなければなりません。
インターセプターとともに、アプリケーションは一つ以上のinterceptor binding typesを定義し、これはターゲットbeanやメソッドにインターセプターを関連付けるアノテーションです。たとえば、billpaymentサンプルはinterceptor binding type named @Loggedとinterceptor named LoggedInterceptorがあります。interceptor binding typeはqualifier宣言に似た宣言ですが、javax.interceptor.InterceptorBindingアノテーションを使用します。
@Inherited @InterceptorBinding @Retention(RUNTIME) @Target({METHOD, TYPE}) public @interface Logged { }
また、interceptor bindingにはjava.lang.annotation.Inheritedがあり、これはアノテーションがスーパークラスから継承されることを意味します。さらに、@Inheritedアノテーションはカスタムスコープを適用します（このチュートリアルでは扱いません）が、qualifiersは適用しません。
interceptor binding typeは他のinterceptor bindingsを宣言可能です。
インターセプタークラスはinterceptor bindingと同様に@Interceptorアノテーションを使用します。例は、The billpayment Example: Using Events and Interceptorsを参照してください。
すべての@AroundInvokeメソッドはjavax.interceptor.InvocationContext引数を取り、java.lang.Objectを返し、Exceptionをスローします。InvocationContextメソッドを呼び出し可能です。@AroundInvokeメソッドはproceedメソッドを呼び出さなければならず、これはターゲットクラスのメソッド呼び出しを行います。
インターセプターとbinding typeを定義すると、beanの全メソッドか特定のメソッドでインターセプターを呼び出すことを指定するために、binding typeをbeanや個々のメソッドにアノテーション付与が可能になります。たとえばbillpaymentサンプルでは、PaymentHandlerbeanには@Loggedアノテーションが付与されており、そのクラスの任意のビジネスメソッド呼び出しが、インターセプターの@AroundInvokeメソッド呼び出しを発生させることを意味しています。
@Logged @SessionScoped public class PaymentHandler implements Serializable {...}
しかし、PaymentBeanbeanでは、payとresetメソッドのみが@Loggedアノテーションを付与されており、よってインターセプターはこれらのメソッドが呼び出されたときのみ呼び出されます。
@Logged public String pay() {...} @Logged public void reset() {...}
CDIアプリケーションで呼び出されるインターセプターはbeans.xmlに指定します。たとえば、LoggedInterceptorクラスは以下のように指定されています。
<interceptors> <class>javaeetutorial.billpayment.interceptors.LoggedInterceptor</class> </interceptors>
もしアプリケーションが一つ以上のインターセプターを使用する場合、インターセプターはbeans.xmlで指定された順に呼び出されます。
beans.xmlで指定するインターセプターは同一アーカイブのクラスにのみ適用されます。複数モジュールで構成されるアプリケーションでインターセプターをグローバルに指定するためには@Priorityを、以下のように使用します。
@Logged @Interceptor @Priority(Interceptor.Priority.APPLICATION) public class LoggedInterceptor implements Serializable { ... }
低プライオリティのインターセプターが最初に呼び出されます。@Priorityアノテーションを使用する場合、beans.xmlにインターセプターを指定する必要はありません。
25.7 Using Decorators in CDI Applications
decoratorは、javax.decorator.Decoratorアノテーションを付与するクラスあるいはbeans.xmlのdecorators要素です。
デコレータbeanクラスはjavax.decorator.Delegateアノテーションを付与したデリゲート注入ポイント(delegate injection point)を持つ必要があります。この注入ポイントは、フィールド・コンストラクタ引数・デコレータクラスの初期化メソッド引数に設定可能です。
デコレータは外見的にはインターセプターに似ています。しかし、デコレータはインターセプターによって実行されるタスクと相互補完的なタスク実行を行います。インターセプターはメソッド実行とbeanのライフサイクルに関連付けられたcross-cuttingタスクを実行しますが、任意のビジネスロジックは実行不可能です。一方デコレータはbeanのビジネスメソッドをインターセプトすることでビジネスロジックを実行します。インターセプターがそうであるように、異なる種類のアプリケーションで再利用可能にする代わりに、そのロジックは特定のアプリケーションに固有であることを意味します。
たとえば、encoderサンプルのalternative TestCoderImplクラスを使う代わりに、デコレータを以下のように作成可能です。
@Decorator public abstract class CoderDecorator implements Coder { @Inject @Delegate @Any Coder coder; public String codeString(String s, int tval) { int len = s.length(); return "\"" + s + "\" becomes " + "\"" + coder.codeString(s, tval) + "\", " + len + " characters in length"; } }
このデコレータを使用するサンプルはThe decorators Example: Decorating a Beanを参照してください。
このシンプルなデコレータは、CoderImpl.codeStringが返すエンコード済み文字列ではなく、詳細な出力を返します。より複雑なデコレータは他のビジネスロジックを実行したりデータベースの情報を格納したり出来ます。
デコレータは抽象クラスとして宣言可能で、その理由はインタフェースのすべてのビジネスロジックを実装する必要が無いからです。
CDIアプリケーションでデコレータをインターセプターやalternativeのように呼び出せるようにするには、beans.xmlに定義が必要です。たとえばCoderDecoratorクラスを以下のように定義します。
<decorators> <class>javaeetutorial.decorators.CoderDecorator</class> </decorators>
アプリケーションが一つ以上のデコレータを使用する場合、デコレータはbeans.xmlで指定される順に呼び出されます。
アプリケーションがインターセプターとデコレータを両方とも持つ場合、最初にインターセプターが呼び出されます。つまり、デコレータはインターセプト出来ません。
beans.xmlで指定するデコレータは同一アーカイブのクラスにのみ適用されます。複数モジュールで構成されるアプリケーションでグローバルなデコレータを指定するには@Priorityアノテーションを、以下のサンプルのように使用します。
@Decorator @Priority(Interceptor.Priority.APPLICATION) public abstract class CoderDecorator implements Coder { ... }
低プライオリティのデコレータが最初に呼び出されます。@Priorityアノテーションを使用する場合、beans.xmlでデコレータを指定する必要はありません。
25.8 Using Stereotypes in CDI Applications
stereotypeとは、他のアノテーションを含む、beanに適用されるアノテーションの一種です。stereotypeは、似たような機能を実行する多数のbeanを有する、大規模アプリケーションで特に有用です。stereotypeは以下を指定するアノテーションの一種です。
- デフォルトスコープ。
- ゼロ個以上のinterceptor bindings。
- オプションで、デフォルEL名を保証するための
@Namedアノテーション。 - オプションで、このstereotypeがalternativeだとすべてのbeanに指定するための
@Alternativeアノテーション。
特定のstereotypeアノテーションが付与されたbeanは常に固有のアノテーションを使用するので、多数のbeanに同じアノテーションを適用する必要はありません。
たとえば、stereotypeのActionをjavax.enterprise.inject.Stereotypeアノテーションを使用して作成したとします。
@RequestScoped @Secure @Transactional @Named @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Action {}
@Actionアノテーションを付与されたすべてのbeanはリクエストスコープ、デフォルトEL名、interceptor bindings@Transactionalと@Secureを持ちます。
また、stereotypeのMockを作成できます。
@Alternative @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Mock {}
このアノテーションが付与されたすべてのbeanはalternativeになります。
同一beanに複数のstereotypeを付与可能で、以下のようなアノテーション付与されたbeanを作成可能です。
@Action @Mock public class MockLoginAction extends LoginAction { ... }
beanごとに異なるスコープを指定するために、stereotypeが指定するスコープをオーバーライドすることも可能です。以下の宣言はMockLoginActionbeanをリクエストスコープではなくセッションスコープに変えています。
@SessionScoped @Action @Mock public class MockLoginAction extends LoginAction { ... }
CDIにはModelと呼ばれる組み込みstereotypeが利用可能で、これはMVCアプリケーションアーキテクチャのモデル層を定義するbeanで使うことを目的としています。このstereotypeは@Namedと@RequestScopedの両方を指定しています。
@Named @RequestScoped @Stereotype @Target({TYPE, METHOD, FIELD}) @Retention(RUNTIME) public @interface Model {}
関連リンク
- The Java EE 7 Tutorialのテキトー翻訳まとめ - Qiita - Java EE 7 Tutorialのうち、自分がテキトー翻訳したものの一覧
