グローバルサービスオプションの構成

サービスのグローバルオプションは、そのすべてのエンティティに適用されます。 オプションは次のとおりです。

• 依存性インジェクター
• パッケージパス
• マルチバージョン同時実行制御
• ネームスペースオプション
• 作成者

依存性インジェクター

デフォルトの依存性注入は、OSGi宣言型サービスです。 これにより、Service Builderは他のモジュールと同様に一貫して動作するようになります。 DXP/Portal 7.2より前は、Service BuilderはSpringの依存性注入を使用していました。 唯一の違いは、サービスを使用する際に、どのようにサービスを注入するかという点です。 両方のインジェクター設定を以下に示します。 詳しくはコアフレームワークの 依存性注入を参照。

宣言型サービス依存性インジェクター：

<service-builder dependency-injector="ds">

Spring依存性インジェクター：

<service-builder dependency-injector="spring">

Service Builder テンプレートを使用してプロジェクトを作成すると、デフォルトで Declarative Services 依存性注入器とその依存関係がプロジェクト用に構成されます。 Spring依存性注入器を使用するには、 Blade CLIのサービスビルダーテンプレートと --dependency-injector spring オプションを使用してプロジェクトを作成します。

注

Liferay DXP/Portal 7.2以前は、Springが唯一の依存性注入ツールでした。 サービスはSpring Beanでした。 LiferayのSpring Beanフレームワークは、相互に参照するSpring Beanに対応しています。たとえば、Spring Bean AにはSpring Bean Bフィールドがあり、その逆も同様です。 Springを依存性注入器として使用する場合、Service Builderはservice.xmlで定義されているすべてのエンティティに対して、ローカルサービスフィールドと永続化フィールドを含む基本サービスを生成します。 これにより、循環参照が発生します。 OSGi Declarative Servicesは循環参照に対応していないため、DSが依存性注入器である場合、Service Builderは基底クラスにこれらのフィールドを作成しません。 詳細については、 生成されたクラスの理解と拡張 を参照してください。

パッケージパス

パッケージパスは、サービスクラスと永続性クラスが生成されるパッケージを指定します。 たとえば、ゲストブックのパッケージパスは次のとおりです。

<service-builder dependency-injector="ds"
        package-path="com.acme.guestbook">

上記のパッケージパスは、*-apiモジュールのサービスクラスがcom.acme.guestbookパッケージで生成されることを保証します。 永続性クラスは、*-serviceモジュール内の同じ名前のパッケージで生成されます。 生成されたクラスの詳細については、 生成されたクラスの理解と拡張 を参照してください。

マルチバージョン同時実行制御（MVCC）

service-builder要素のmvcc-enabled属性は、デフォルトではfalseです。 mvcc-enabled="true" を設定すると、すべてのエンティティに対して マルチバージョン同時実行制御 (MVCC) が有効になります。 システムでは、同時更新が一般的です。 MVCCがない場合、ユーザーは気づかないうちに無効な状態のデータを読み取ったり上書きしたりしてしまう可能性があります。 MVCCでは、各変更は特定の基本バージョン番号に基づいて行われます。 Hibernate永続レイヤーは更新を受信すると、update SQLステートメントを生成します。このステートメントでは、where句を使用して現在のデータバージョンが期待するバージョンであることを確認します。

現在のデータバージョンが

• 予想されるバージョンと一致する場合、データ操作は最新のデータに基づいており、受け入れられます。

• 期待されるバージョンと一致しない場合、操作しているデータが古くなっています。 DXP/Portalはデータ操作を拒否し、例外をスローします。例外をキャッチすると、ユーザーが例外を処理するのに役立ちます（操作の再試行を提案するなど）。

mvcc-enabled="true" を <service-builder/> 要素に設定して、すべてのサービスで MVCC を有効にします。 サービスエンティティの更新（例：fooService.update(object)）を呼び出すときは、必ずトランザクションで呼び出してください。 ユーザーが処理できるように、UIで拒否されたトランザクションを公開してください。

<service-builder dependency-injector="ds"
        package-path="com.acme.guestbook"
        mvcc-enabled="true">

ネームスペースオプション

サービスビルダーは、サービスのネームスペースを使用してデータベーステーブルに名前を付けます。 たとえば、GBはゲストブックアプリケーションサービスのネームスペースとして機能できます。

<service-builder dependency-injector="ds"
   package-path="com.acme.guestbook"
   mvcc-enabled="true">
    <namespace>GB</namespace>
    <author>Liferay</author>

サービスビルダーは、src/main/resources/sqlフォルダに生成される次のSQLスクリプトのネームスペースを使用します。

• indexes.sql
• sequences.sql
• tables.sql

注

生成されたSQLスクリプトのフォルダ場所は設定可能です。 例えば、Gradle を使用している場合は、以下の例で databaseNameMaxLength 設定が適用されているように、プロジェクトの Gradle build.gradle ファイルで sqlDir 設定を定義できます。

サービスビルダーは、SQLスクリプトを使用して、service.xmlが定義するすべてのエンティティのデータベーステーブルを作成します。 データベーステーブル名には、作成時にネームスペースが付加されます。 例のネームスペースの値は GBなので、エンティティ用に作成されるデータベース テーブル名は、プレフィックスとして GB_ で始まります。 各サービスビルダープロジェクトのネームスペースは一意である必要があります。 個別のプラグインは個別のネームスペースを使用する必要があり、Liferayエンティティ（UsersやGroupsなど）ですでに使用されているネームスペースを使用しないでください。 Liferayのデータベースのテーブル名をチェックして、すでに使用されているネームスペースを確認してください。

名前空間の値は慎重に割り当ててください。 一部のデータベースには、データベーステーブルと列名の長さに強い制限があります。 Service Builder Gradle プラグイン パラメータ databaseNameMaxLength は、テーブル名と列名に使用できる最大長を設定します。 以下に、ビルドファイルでdatabaseNameMaxLengthを設定する例をいくつか示します。

Gradle build.gradle

buildService {
    ...
    databaseNameMaxLength = 64
    ...
}

作成者

グローバル情報の最後の部分として、service.xmlファイルにサービスの作成者としての名前を入力します。 サービスビルダーは、生成するすべてのJavaクラスとインターフフェイスに指定された名前の@authorアノテーションを追加します。 service.xml ファイルを保存します。 次に、サービスのエンティティを追加します。

<service-builder dependency-injector="ds"
   package-path="com.acme.guestbook"
   mvcc-enabled="true">
    <namespace>GB</namespace>
    <author>Liferay</author>

関連トピック

• コアフレームワーク
• 生成されたクラスの理解と拡張