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

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

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

依存性インジェクター

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

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

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

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

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

サービスビルダーテンプレート を使用してプロジェクトを作成する場合、宣言型サービスの依存性インジェクターとその依存性は、デフォルトでプロジェクト用に構成されています。 代わりにSpring依存性インジェクターを使用するには、Blade CLIのサービスビルダーテンプレートと--dependency-injector springオプションを使用してプロジェクトを作成します。

note

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

パッケージパス

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

<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はデータ操作を拒否し、例外をスローします。例外をキャッチすると、ユーザーが例外を処理するのに役立ちます(操作の再試行を提案するなど)。

重要: <service-builder/>要素でmvcc-enabled="true"を設定して、すべてのサービスで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
note

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

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

警告: ネームスペースの値の割り当てには注意が必要です。 一部のデータベースには、データベーステーブルと列名の長さに強い制限があります。 サービスビルダーの 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>