【後編】OSGiアノテーションとは?その紹介と活用法 - 【後編】OSGiアノテーションとは?その紹介と活用法 - Japan

null 【後編】OSGiアノテーションとは?その紹介と活用法
by Yasuyuki Takeo

【後編】OSGiアノテーションとは?その紹介と活用法

画像

こんにちは。
日本ライフレイ、サポータビリティエンジニアの竹生(たけお)です。

前回の記事にて、いくつかの代表的なOSGiアノテーションの紹介と利用どころについて紹介しました。今回はその後編です。

前編と同様、本記事も以下の知識レベルの方たち、ユースケースが対象です。ご参照ください。


■ 本記事対象の知識レベルとユースケース

  • 中級レベル
  • 一般的なLiferay DXP開発に必須

*レベルの定義については、こちらのブログの冒頭で紹介しています。


Liferay 7CEやLiferay DXPコードのレビューをしていると、さまざまな種類のアノテーションを目にする機会があるかと思います。初めてそれらを見ると、その種類の多さに圧倒されてしまう方も多いのではないでしょうか。そこで本記事では、代表的なアノテーションの説明と、それらをいつOSGiコードで使用するか、簡単にまとめてご紹介します。

前編で紹介したアノテーションもあわせて御覧ください。

前回記事:【前編】OSGiアノテーションとは?その紹介と活用法

それではさっそく残りのアノテーションも見てみましょう。

@Activate

※本記事はLiferay Community Blogに投稿されている”Liferay/OSGi Annotations - What they are and when to use them”を翻訳したものです。配信元または著者の許可を得て配信しています。 オリジナルの英記事著者:David H Nebinger サウスカロライナ州のサマーヴィルに住むLiferay, Inc.のSoftware Architect/リードコンサルタント。Liferay Communityサイトにて、多くの技術情報を投稿するなど精力的に活動しています。

@Activateアノテーションは、OSGiにおけるSpringのInitializingBeanインタフェースに相当します。コンポーネントの起動後に、呼び出されるメソッドを宣言します。

Liferayソースでは、以下のような3つの主要なメソッドシグネチャが使用されています。


@Activate
protected void activate() {
  ...
}
@Activate
protected void activate(Map properties) {
  ...
}
@Activate
protected void activate(BundleContext bundleContext, Map properties) {
  ...
}

他にもメソッドシグネチャがあり、Liferayソースで@Activateを検索すればすべてのバリエーションを見ることができます。引数なしのactivateメソッドを除いて、それらはすべてOSGiによって注入された値に依存します。プロパティマップは実際にはOSGiのConfiguration Adminサービスのプロパティです。@Activeアノテーションはいつ使うかですが、 コンポーネントの起動後、もしくは利用前に初期化を完了する必要があるときはいつでも使います。私はQuartzジョブの設定やスケジューリング、データベースエンティティの検証などに使用しています。

@Deactivate

@Deactivateアノテーションは、@Activateアノテーションの逆であり、コンポーネントが非アクティブ化されているときに呼び出されるメソッドを識別します。

@Modified

@Modifiedアノテーションは、コンポーネントが変更されたときに呼び出されるメソッドを識別します。通常、@Reference(s)が変更されたことを示します。 Liferayコードでは、@Modifiedアノテーションは多くの場合@Activateアノテーションと同じメソッドにバインドされているため、同じメソッドのアクティブ化と変更の両方を処理します。

@ProviderType

@ProviderTypeはBNDに由来するのですが、複雑で扱いずらいと感じる方も多いのではないでしょうか。簡単な説明をすると、@ProviderTypeは、実装者のOSGiマニフェストに割り当てられたバージョン範囲を定義するためにBNDによって使用され、範囲を狭いバージョンの違いに制限しようとします。

これによって、インタフェースが変更されたときに、それより狭いバージョン範囲の実装があった場合に、実装のアップデートを強いることで、新しいインタフェースのバージョンと一致させた実装が、必ずシステムに配置されていることを保証することができます。

@ProviderTypeはいつ使うかですが、実をいうと、必要ではありません。このアノテーションは、ServiceBuilderで生成されたコード全体に散らばって表示されます。これは、実装者が使う必要があるからではなく、それらを見てなぜそこにあるのかと疑問に思うのを解消するためにあります。

@ImplementationClassName

@ImplementationClassNameは、ServiceBuilderエンティティインターフェイスのLiferayアノテーションです。インタフェースを実装するサービスモジュールのクラスを定義します。

これは、使用する必要があるインターフェイスではありませんが、少なくともなぜそこにあるのかを知っておくことが重要です。

@Transactional

@TransactionalはServiceBuilderサービスインターフェイスにバインドされた別のLiferayアノテーションです。これは、サービスメソッドのトランザクション要件を定義します。これも使用する必要はないアノテーションのひとつつです。

@Indexable

@Indexableアノテーションは、通常、エンティティを追加、更新、または削除するServiceBuilderメソッドに関連付けられ、インデックスを更新するメソッドを装飾するために使用されます。

@Indexableアノテーションは、インデックスエンティティの追加、更新、または削除するサービス実装メソッドで使用します。エンティティのcom.liferay.portal.kernel.search.Indexer実装が関連付けられている場合、インデックスが作成されているかどうかがわかります。

@SystemEvent

@SystemEventアノテーションは、ServiceBuilder生成コードに関連付けられているため、システムイベントが発生する可能性があります。システムイベントは、ステージングおよびLARエクスポート/インポートプロセスと連携して動作します。たとえば、記事が削除されると、SystemEventレコードが生成されます。ステージング環境で、「本番へ公開する」処理が発生すると、delete SystemEventによって、本番の対応する記事も確実に削除されます。

@SystemEventはいつ使うか? 正直いって、私もよくわかっていません笑。 10年間のOSGi開発経験で、SystemEventレコードを生成したり、パブリケーションやLARプロセスを変更したりする必要はありませんでした。 もし、@SystemEventアノテーションを使用したり変更したりしなければならない状況を経験した方がいたら、ぜひユースケースについて聞いてみたいと思います。

@Meta

OSGiには、Configuration Adminの設定の詳細を定義するXMLベースのシステムがあります。 BNDプロジェクトの@Metaアノテーションにより、BNDは設定インタフェースで使用されるアノテーションに基づいて、ファイルを生成することができます

注意ポイント:@Metaアノテーションを使用するには、次の行をbnd.bndファイルに追加する必要があります。


-metatype: *

上記を追加しなければ、@MetaアノテーションはXML設定ファイルを生成するときに使用されません。

@Meta.OCD

@Meta.OCDは、設定詳細のコンテナである、「オブジェクトクラス定義」のためのアノテーションです。このアノテーションは、クラス定義のID、名前、およびローカライゼーションの詳細を提供するために、インターフェースレベルで使用されます。

@Meta.OCDは コンポーネントを設定するために、システム設定コントロールパネルにパネルを持つAdmin設定インターフェースを定義するときに使います。

@Meta.OCD属性には、ローカライズ設定が含まれています。これにより、リソースバンドルを使用して、構成名、フィールドレベルの詳細、および@ExtendedObjectClassDefinitionカテゴリをローカライズすることができます。

 

@Meta.AD

@Meta.ADは、構成要素の仕様を定義するための項目レベルのアノテーションである:「属性定義」のアノテーションです。このアノテーションは、ID、名前、説明、デフォルト値、およびフィールドのその他の詳細を提供するために使用されます。

@Meta.ADはシステム設定の設定パネルで、レンダリング方法を制御するフィールド定義の詳細を提供する際に使用します。

@ExtendedObjectClassDefinition

@ExtendedObjectClassDefinitionは、設定のカテゴリ(システム設定コントロールパネルのタブが設定される場所を識別するため)と、設定の範囲を定義するためのLiferayアノテーションです。

意味は次のいずれかになります。

  • SYSTEM - システム全体のグローバル構成。システム全体を共有する構成インスタンスは1つのみ。
  • COMPANY - ポータル内のカンパニーIDごとに1つの設定インスタンスを許可する、企業レベルの設定。
  • GROUP - サイト毎レベルの構成インスタンスを許可する、グループレベル(サイト)構成。
  • PORTLET_INSTANCE - ポートレット・インスタンス設定のスコープと似ており、ポートレット・インスタンスごとに個別の構成インスタンスが存在する。

ExtendedObjectClassDefinitionは@ Meta.OCDアノテーションを使用する際は毎回、@ExtendedObjectClassDefinitionアノテーションを使用し、構成が追加されるタブを定義します。

@OSGiBeanProperties

@OSGiBeanPropertiesは、OSGiコンポーネントとしてSpring Beanを登録するために使用される、Liferayアノテーションです。ServiceBuilderモジュールで頻繁に使用され、Spring BeanをOSGiコンテナに公開しています。一点、ServiceBuilderはまだSpring(およびSpringExtender)ベースであることを忘れないでください。このアノテーションは、これらのSpring BeanをOSGiコンポーネントとして公開します。

@OSGiBeanPropertiesはモジュール内でSpringを使用する場合や、Spring Extenderを使用している場合に、他のモジュールがBeanを使用できるようにSpring BeanをOSGiに公開したい場合に、このアノテーションを使います。

@OSGiBeanPropertiesアノテーションのコードは広範にjavadocされているため、ここでの説明は割愛しています。詳細を知りたい方はぜひこちらを確認してみてください(英語)→https://github.com/liferay/liferay-portal/blob/master/portal-kernel/src/com/liferay/portal/kernel/spring/osgi/OSGiBeanProperties.java

 

まとめ

いかがでしたでしょうか?

少し長くなってしまいましたが、私がLiferay 7 CE / Liferay DXPでこれまでに遭遇したすべてのアノテーションを紹介してみました。これらの詳細情報が、みなさんのLiferay開発に役立てば幸いです。 私が見逃しているアノテーション見つけたり、もっと詳細をしりたいものがあれば、いつでも聞いてください。

本記事のお問い合わせはこちらまで→yasuyuki.takeo@liferay.com

 


■ これまで発信してきた日本語による技術コンテンツを、Qiitaでお読みいただけます。よろしければそちらの記事も合わせてご役立てください。
https://qiita.com/yasuflatland-lf

Doorkeeperのライフレイコミュニティメンバー大歓迎!
コーポレートブログの技術コンテンツ更新情報など定期的におとどけしています。
https://liferay.doorkeeper.jp/

業界最高の評価

 

Gartner

ライフレイは9年連続で、ガートナー社によるデジタルエクスペリエンスプラットフォーム分野のマジック・クアドラントにおいて、Adobe社やIBM社と並ぶリーダーに選出されました。

レポートの詳細はこちら