.. only:: html

 .. contents:: 目次
    :depth: 2
    :local:

5.5.1での主な変更点は以下の通りです。

• 依存関係の管理をSpring Bootが提供するspring-boot-dependenciesで行うよう変更
• Java SE 7がサポート対象外となり、新規にJava SE 11のサポートを開始
• Spring Frameworkを5.1.4へ更新
• Spring Securityを5.1.3へ更新
• MyBatisを3.5.0へ更新
• Hibernate ORMを5.3.7へ更新
• Hibernate Validatorを6.0.14へ更新(Bean Validationが1.1から2.0に更新)
• Dozerを6.4.1へ更新
• 共通ライブラリの仕様を一部変更
• ブランクプロジェクトの変更

依存関係の管理をSpring IO Platformから、Spring Bootが提供するspring-boot-dependenciesで行うよう変更しました。 spring-boot-dependenciesは2.1.2.RELEASEを利用します。

Note

依存関係の管理をspring-boot-dependenciesに変更したことで一部のライブラリのバージョンが管理されなくなりました。 バージョンが管理されなくなったライブラリの内、TERASOLUNA Server Framework for Javaで使用しているものは、共通ライブラリで管理を行うように変更しました。

spring-boot-dependencies及び、共通ライブラリで管理されていないライブラリは、プロジェクトごとに独自に管理を行う必要があります。 Spring Bootのリファレンスと 共通ライブラリで使用するOSSの一覧を参照し、管理が必要なライブラリを確認してください。

Java SE 7をサポート対象外とし、互換性を考慮しなくなりました。 また、新規にJava SE 11のサポートを開始しました。

5.5.1から、Spring Framework 5.1.4.RELEASEへ更新しました。

5.5.1から、Spring Security 5.1.3.RELEASEへ更新しました。

5.5.1から、MyBatis 3.5.0へ更新しました。この更新にあわせて、MyBatis Springを2.0.0へ更新しました。

5.5.1から、Hibernate ORM 5.3.7.Finalへ更新しました。

5.5.1から、Hibernate Validator 6.0.14.Final(Bean Validation 2.0)へ更新しました。

5.5.1から、Dozer 6.4.1へ更新しました。

5.5.1から、共通ライブラリの一部仕様の変更と機能の追加を行いました。

• [#11] SimpleI18nCodeList is not reloadble
• [#363] Support fallback language at SimpleI18nCodeList
• [#736] Fix inappropriate dependency on terasoluna-gfw-jodatime
• [#757] f:query and f:u not work correctly on Spring Framework 5
• [#761] Suggest to add constraint annotation that validate a byte size range
• [#803] Resolve a locale using LocaleContextHolder on AbstractI18nCodeList.asMap
• [#858] Apply Spring Boot Dependencies 2.1
• [#859] Apply MyBatis 3.5.0
• [#862] Update Google Guava to 27.0.1-jre
• [#868] Update spring-security-oauth2 to 2.2.4.RELEASE
• [#877] @ExistInCodeList support Number for NumberRangeCodeList

5.5.1から、バグ修正に伴い共通ライブラリの一部仕様を変更しました。

• [#796] Can't validate SimpleI18nCodelist by @ExsitInCodeList
• [#809] JdbcCodeList improperly updates the code list map already registered in request

5.5.1から、ブランクプロジェクトの一部設定ファイルを変更しました。

• [single#312] [multi#348] Improve mvc:exclude-mapping Definition of interceptors in spring-mvc.xml for security
• [single#370] [multi#424] Change password encoder for bcrypt to pbkdf2
• [single#393] [multi#443] Apply @ByteSize
• [single#396] [multi#445] Update JDBC driver

移行手順は、以下の通りです。

Note

凡例

Required : 手順の適用は必須

Required by case : 手順の適用は条件付きで必須

Optional : 手順の適用を推奨 (必要に応じて手順の適用を実施)

- : 手順の適用は必要なし

[全般]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[共通ライブラリ]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Blank project]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Spring Framework]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Spring Security]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Hibernate ORM]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Hibernate Validator]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Dozer]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

TERASOLUNA Server Framework for Java (5.x)の共通ライブラリと依存ライブラリを更新してください。 以下に、この手順により更新される代表的な依存ライブラリを示します。

.. tabularcolumns:: |p{0.35\linewidth}|p{0.25\linewidth}|p{0.25\linewidth}|p{0.15\linewidth}|

[手順が必要なケース]

この手順の適用は必須です。

この更新手順は、mvn archetype を使用して作成したプロジェクト向けです。

親プロジェクトのpomファイルの version を 5.5.1.RELEASE に修正してください。

• ($YOUR_MULTIPLE_PROJECT_ROOT/pom.xml)

<!-- omitted -->
<parent>
    <groupId>org.terasoluna.gfw</groupId>
    <artifactId>terasoluna-gfw-parent</artifactId>
    <version>5.5.1.RELEASE</version>                    <!-- ### 修正箇所 ### -->
</parent>
<!-- omitted -->

この更新手順は、mvn archetype を使用して作成したプロジェクト、又は release site からダウンロードしたプロジェクト向けです。

プロジェクトのpomファイルの version を 5.5.1.RELEASE にしてください。

• ($YOUR_SINGLE_PROJECT/pom.xml)

<!-- omitted -->
<parent>
    <groupId>org.terasoluna.gfw</groupId>
    <artifactId>terasoluna-gfw-parent</artifactId>
    <version>5.5.1.RELEASE</version>                    <!-- ### 修正箇所 ### -->
</parent>
<!-- omitted -->

TERASOLUNA Server Framework for Java 5.5.1からJava SE 7がサポート対象外となったため、Java SE 8への移行を行ってください。

[手順が必要なケース]

実行環境でJava 7を利用している場合、この手順は必須です。

[修正方法]

実行環境で利用するJavaをJava 8に変更してください。

また、アプリケーションをJava SE 8へ移行するため、以下の手順を実施してください。

pomファイルのプロパティを修正し、利用するJavaのバージョンを変更してください。

<properties>
    <!-- omitted -->
    <java-version>1.8</java-version> <!-- ### 修正箇所 ### -->
</properties>

Java SE 7とJava SE 8には非互換が存在するため、影響の有無を確認し、適宜修正を行ってください。 非互換性の詳細はJava SE 8とJava SE 7の非互換性を参照してください。

[備考]

サポート対象外ですが、ソースコードをJava SE 7互換でコンパイルする必要がある場合は、`` java-version``を1.7のままにします。 この場合、Java SE 8に依存する一部の機能が使用できなくなる他、Java SE 8との非互換性により意図しない動作をする可能性があります。 必ず十分な動作検証を行い、問題がないことを確認してください。

SimpleI18nCodeList のロケール解決における仕様を以下の通り変更しました。 新規に追加された SimpleIReloadable18nCodeList も同様の実装となります。

• CodeListInterceptor におけるロケール解決を廃止し、 SimpleI18nCodeList にロケール解決の仕組みを導入しました。
• SimpleI18nCodeList#asMap() メソッドに LocaleResolver （国際化対応）に準拠したロケール解決の仕組みを導入しました。
• 指定されたロケールのコードリストが存在しない場合に適切なロケールにフォールバックする仕組みを導入しました。

CodeListInterceptorにおけるロケール解決を廃止し、SimpleI18nCodeList にロケール解決の仕組みを導入

CodeListInterceptor におけるロケール解決を廃止し、 SimpleI18nCodeList にロケール解決の仕組みを導入しました。

従来はJSPでリクエストスコープから SimpleI18nCodeList を取得する場合は適切にロケール解決が行われましたが、 Controller 等で取得する場合やJSPでBeanとして取得する場合には独自にロケール解決を行う必要がありました。

この変更により、どの場合でも同じルールに基づき適切なロケールのコードリストを取得することが可能になりました。 ただし、今まで CodeListInterceptor の fallbackTo プロパティでフォールバックロケールを指定していた場合は、 SimpleI18nCodeList ごとに指定する必要があります。

SimpleI18nCodeList#asMap()メソッドにLocaleResolver（国際化対応）に準拠したロケール解決の仕組みを導入

SimpleI18nCodeList#asMap() メソッドでSpringで提供される LocaleContextHolder を利用することで、 LocaleResolverに準拠したロケールのコードリストを取得できるようになりました。

従来の asMap() メソッドでは Locale#getDefault によりJVMのデフォルトロケールのコードリストを取得していましたが、 これは LocaleResolver で提供されるリクエストのロケールと乖離することがありました。 これにより、例えば asMap() メソッドを利用する @ExistInCodeList では、入力値が SimpleI18nCodeList に存在するかどうかチェックすることができませんでした。

この変更により、独自にロケール解決を行っていた箇所は、 asMap() メソッドを利用することで代替することが可能となります。 また、@ExistInCodeListでSimpleI18nCodeListの存在チェックが可能になりました。

指定されたロケールのコードリストが存在しない場合に適切なロケールにフォールバックする仕組みを導入

従来の SimpleI18nCodeList では、言語のみのロケールと国と言語のロケールが別々に認識されていたため、 例えば英語圏で使用する場合は言語のみのenと国と言語のen_US、en_BRなど使用される可能性のあるロケールを列挙する必要があり、設定が煩雑でした。 また、列挙から漏れたロケールはコードリストが取得できず、本番環境や開発の後工程で設定不足が露見しやすい仕様でした。

これを解決するため、指定されたロケールに対応するコードリストがない場合は適切なロケールにフォールバックする仕組みを導入しました。

• 国と言語のロケールに該当しない場合、言語のみのロケールにフォールバックする
• 言語のみのロケールに該当しない場合、デフォルトロケールにフォールバックする

デフォルトロケールは fallbackTo プロパティで指定することができ、指定がない場合はJVMのデフォルトロケールが採用されます。 デフォルトロケールか、これに対応する言語のみのロケールのコードリストが定義されていない場合、アプリケーション起動時にエラーとなります。

この変更により、ロケールに対応するコードリストの設定が簡潔となり、設定不足によりコードリストが取得できないことが無くなりました。 ただし、設定されていないロケールが指定された場合に意図的にコードリストを取得していなかったアプリケーションでは、コードリストが取得できるよう変更されますので、ご注意ください。

[手順が必要なケース]

SimpleI18nCodeList を利用している場合、以下のケースに当てはまるか確認を行ってください。

次のケースと一致する場合、この手順の適用は必須です。

• CodeListInterceptor の fallbackTo プロパティでフォールバックロケールを指定している場合。
• SimpleI18nCodeList の asMap() メソッドを用いてJVMのデフォルトロケールを取得している場合。
• アプリケーション起動時にエラーとなり、ログにエラーメッセージ "No codelist found for fallback locale 'ロケール', it must be defined."が表示される。

以下のいずれかのケースと一致する場合、この手順の適用は任意ですが修正を行うことを推奨します。

• SimpleI18nCodeList の入力チェックを独自に実装している場合。
• 特定の言語に対応するために、言語のみのロケールと国と言語のロケールのコードリストを定義している場合。
• 指定されたロケールのコードリストが存在しないとき、JVMのデフォルトロケール以外にフォールバックしたい場合。
• JVMのデフォルトロケールが、LocaleResolver のデフォルトロケールと一致しない場合。

[修正方法]

[ CodeListInterceptor の fallbackTo プロパティでフォールバックロケールを指定している場合]

spring-mvc.xml に設定している CodeListInterceptor から fallbackTo プロパティを削除してください。

• spring-mvc.xml の定義例

<mvc:interceptors>
    <mvc:interceptor>
        <mvc:mapping path="/**" />
        <bean class="org.terasoluna.gfw.web.codelist.CodeListInterceptor">
            <property name="codeListIdPattern" value="CL_.+" />
            <property name="fallbackTo" value="ja" /> <!-- ### 削除箇所 ### -->
        </bean>
    </mvc:interceptor>

<!-- omitted -->

</mvc:interceptors>

CodeListInterceptor の対象になっていた SimpleI18nCodeList に対して、fallbackTo プロパティを設定してください。 設定するロケールは CodeListInterceptor に設定されていたものと同じになります。 また、 fallbackToプロパティに設定したロケールのコードリストを必ず設定するようにしてください。

• コードリストのbean定義例

<bean id="CL_I18N_PRICE"
    class="org.terasoluna.gfw.common.codelist.i18n.SimpleI18nCodeList">
    <property name="rowsByCodeList">
        <util:map>
            <entry key="ja" value-ref="(ja用CodeListのID)" />
            <entry key="en" value-ref="(en用CodeListのID)" />
        </util:map>
    </property>
    <property name="fallbackTo" value="ja" /> <!-- ### 追加箇所 ### -->
</bean>

[ SimpleI18nCodeList の asMap() メソッドを用いてJVMのデフォルトロケールを取得している場合]

asMap() メソッドを呼び出した際のコードリストのロケールがJVMのデフォルトロケールから変更されました。 この仕様変更による影響がある場合は、適宜 asMap(Locale) メソッドに置き換えを行ってください。

[アプリケーション起動時にエラーとなり、ログにエラーメッセージ "No codelist found for fallback locale 'ロケール', it must be defined."が表示される]

このエラーはデフォルトのロケールに対応するコードリストが設定されていない場合に発生します。 SimpleI18nCodeList にエラーメッセージに表示されたロケールでコードリストを設定してください。

[ SimpleI18nCodeList の入力チェックを独自に実装している場合]

@ExixtInCodeList による存在チェックでは asMap() メソッドを使用してコードリストを取得するため、今回の変更により正常にリクエストに対応するロケールのコードリストを取得するようになりました。 今までの不具合により別の手段で存在チェックを行っていた場合は、@ExixtInCodeList によるチェックに置き換えることで SimpleI18nCodeList の仕様変更に対応したチェックを行うことが可能です。

@ExistInCodeList の実装方法についてはコードリストを用いたコード値の入力チェックを参照してください。

[特定の言語に対応するために、言語のみのロケールと国と言語のロケールのコードリストを定義している場合]

言語とコードリストが一対一で対応しており、言語のみのロケールと国と言語のロケールの設定が同じであれば、言語のみのロケールに統一して国と言語のロケールの設定を削除してください。 国ごとの方言を意識して複数のコードリストを用意している場合は、間違って削除しないよう注意してください。

• コードリストのbean定義例

<bean id="CL_I18N_PRICE"
    class="org.terasoluna.gfw.common.codelist.i18n.SimpleI18nCodeList">
    <property name="rowsByCodeList">
        <util:map>
            <entry key="ja" value-ref="(ja用CodeListのID)" />
            <entry key="ja_JP" value-ref="(ja用CodeListのID)" /> <!-- ### 削除箇所 ### -->
            <entry key="en" value-ref="(en用CodeListのID)" />
            <entry key="en_US" value-ref="(en用CodeListのID)" /> <!-- ### 削除箇所 ### -->
            <entry key="en_BR" value-ref="(en用CodeListのID)" /> <!-- ### 削除箇所 ### -->
        </util:map>
    </property>
</bean>

[指定されたロケールのコードリストが存在しないとき、JVMのデフォルトロケール以外にフォールバックしたい場合]

SimpleI18nCodeList に fallbackTo プロパティを指定し、デフォルトのロケールの設定を行ってください。

<bean id="CL_I18N_PRICE"
    class="org.terasoluna.gfw.common.codelist.i18n.SimpleI18nCodeList">
    <property name="rowsByCodeList">
        <util:map>
            <entry key="en" value-ref="(en用CodeListのID)" />
            <entry key="ja" value-ref="(ja用CodeListのID)" />
        </util:map>
    </property>
    <property name="fallbackTo" value="en" /> <!-- ### 追加箇所 ### -->
</bean>

[JVMのデフォルトロケールが、LocaleResolver のデフォルトロケールと一致しない場合]

SimpleI18nCodeList に fallbackTo プロパティを指定し、LocaleResolver のデフォルトロケールと同一のロケールを設定してください。

Bean定義については上記の「JVMインスタンスのデフォルトロケールが、デフォルトとして設定したい言語のロケールと一致しない場合」を参照してください。

LocaleResolver のデフォルトロケールについては、開発ガイドラインの国際化を参照してください。

ReloadableCodeList （ JdbcCodeList 等）の asMap メソッドにより Map として取得されるコードリストがイミュータブルに変更されました。

従来の ReloadableCodeList では、コードリストを取得した後に refresh メソッドでコードリストがリロードされると、 既に asMap メソッドで取得された Map の中身も更新される（イミュータブルでない）という問題がありました。 このため例えば、Controllerで Map キーの存在チェックを行った後、実際にキーを指定して値を取得しようとすると null が得られるようなケースが発生し得ました。

この変更に伴い、 CodeListInterceptor がリクエストスコープにコードリストを登録するタイミングが、Controllerの処理実行前（ preHandle メソッド）から処理実行後（ postHandle メソッド）に変更されました。 なお、 postHandle メソッドはControllerの処理で例外がスローされた場合は実行されない点にご注意ください。（Controllerの処理でTry-Catchされた場合は除きます。）

今回の改善により、従来の実装では期待通りにコードリストを取得できなくなる場合があります。

[手順が必要なケース１]

CodeListInterceptor がリクエストスコープに登録したコードリストをControllerで取得している場合。

[修正方法]

Controllerの処理実行時はリクエストスコープからコードリストを取得することができなくなります。 ControllerにコードリストBeanをインジェクションし、 asMap メソッドによりコードリストを取得してください。

【修正前】※コード例は一例です。

@RequestMapping
public String handle(HttpServletRequest request) {

    Map<String, String> codeListMap = request.getAttribute("CL_SAMPLE");

    // ommited logics
}

【修正後】

@Inject
@Named("CL_SAMPLE")
CodeList codeList;

@RequestMapping
public String handle() {

    Map<String, String> codeListMap = codeList.asMap();

    // ommited logics
}

[手順が必要なケース２]

Controllerの処理で例外がスローされた場合に遷移する画面でコードリストを利用している場合。（Controllerの処理でTry-Catchされた場合は除きます。）

[修正方法]

Controllerの処理で例外がスローされた場合はリクエストスコープからコードリストを取得することができなくなります。 JSPでコードリストBeanを参照し、 asMap メソッドによりコードリストを取得してください。

【修正前】

<form:select items="${statuses}" path="orderStatus" />

【修正後】

<spring:eval var="statuses" expression="@CL_ORDERSTATUS.asMap()"/>
<form:select items="${statuses}" path="orderStatus" />

TraceLoggingInterceptorでwarnHandlingNanosを設定する実装例が修正されました。

以前の実装例ではTraceLoggingInterceptorのwarnHandlingNanosプロパティに数式#{10 * 1000 * 1000 * 1000}を指定し、Controllerの処理時間が10000000000ナノ秒（10秒）を超えるとWARNログが出力することを期待していました。 実際には10000000000はintの最大値2147483647を超えるためオーバーフローによって1410065412が指定され、Controllerの処理時間が1410065412ナノ秒（約1.4秒）を超えるとWARNログが出力されてしまう形となります。

[手順が必要なケース]

以下のケースと一致する場合は、次の修正を行ってください。

• TraceLoggingInterceptorのwarnHandlingNanosプロパティに、int型の数式かint型の数式を値として持つプロパティを指定している場合。

[修正方法]

warnHandlingNanosの設定を以下のいずれかのように変更してください。

【修正前】

<mvc:interceptors>
    <!-- omitted -->
    <mvc:interceptor>
        <mvc:mapping path="/**" />
        <mvc:exclude-mapping path="/resources/**" />
        <bean
            class="org.terasoluna.gfw.web.logging.TraceLoggingInterceptor">
            <property name="warnHandlingNanos" value="#{10 * 1000 * 1000 * 1000}" />
        </bean>
    </mvc:interceptor>
    <!-- omitted -->
</mvc:interceptors>

【修正後】

• long型の数式を指定する

<mvc:interceptors>
    <!-- omitted -->
    <mvc:interceptor>
        <mvc:mapping path="/**" />
        <mvc:exclude-mapping path="/resources/**" />
        <bean
            class="org.terasoluna.gfw.web.logging.TraceLoggingInterceptor">
            <property name="warnHandlingNanos" value="#{10L * 1000L * 1000L * 1000L}" />
        </bean>
    </mvc:interceptor>
    <!-- omitted -->
</mvc:interceptors>

• 固定値で指定する

<mvc:interceptors>
    <!-- omitted -->
    <mvc:interceptor>
        <mvc:mapping path="/**" />
        <mvc:exclude-mapping path="/resources/**" />
        <bean
            class="org.terasoluna.gfw.web.logging.TraceLoggingInterceptor">
            <property name="warnHandlingNanos" value="10000000000" />
        </bean>
    </mvc:interceptor>
    <!-- omitted -->
</mvc:interceptors>

Spring Framework 4までクエリ文字として使用できていた"+"の文字が、Spring Framework 5 よりエンコーディング対象外となりました。 クエリ文字列のエンコードを行うorg.springframework.web.util.UriComponentsBuilderやorg.springframework.web.util.UriUtils.encodeQueryParamメソッドは仕様変更され、"+"がエンコードされなくなりました。

共通ライブラリのf:query()、f:u()は上記の仕様変更されたクラスを内部で利用していますが、独自に"+"をエンコーディングすることで仕様変更の影響を受けないようにしています。

[手順が必要なケース]

f:query()やf:u()のエンコーディングに合わせるために、UriComponentsBuilder等を利用している場合は仕様変更の影響がないか確認を行ってください。

[備考]

UriComponentsBuilderでは、クエリパラメータに含まれるunreserved文字以外をエンコーディングする機能を提供しています。 この機能を用いる事でクエリパラメータに含まれる "+" のエンコーディングは可能です。

5.4.1の共通ライブラリでは、バグにより不要なcommons-loggingへの依存関係を持っていました。

このバグは、Spring IO PlatformからSpring FrameworkおよびSpring Securityを独自にバージョンアップしていたことが原因で発生していましたが、 5.5.1では、これらのライブラリはspring-boot-dependenciesに準拠するようになったため発生しなくなりました。

[手順が必要なケース]

この手順は任意ですが、以下のケースに一致する場合は、次の修正を適用することを推奨します。

• commons-loggingの除外設定を行っている。

[修正方法]

以下の実装例を参考に、不要となったcommons-loggingの除外設定を削除してください。

• pom.xmlの定義例

<dependencyManagement>
  <dependencies>
    <!-- ### 削除箇所 開始 ### -->
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-core</artifactId>
      <exclusions>
        <exclusion>
          <groupId>commons-logging</groupId>
          <artifactId>commons-logging</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <!-- ### 削除箇所 終了 ### -->

    <!-- omitted -->

  </dependencies>
</dependencyManagement>

[備考]

commons-loggingの除外設定を行っておらず、当該APIを誤って使用していた場合は、バージョンアップによりコンパイルエラーとなります。 この場合、commons-loggingからSLF4JのAPIに置き換えることをご検討ください。

サポートするApache POIのバージョンが3.15から3.17にバージョンアップしました。

Apache POI 3.17では、削除予定であった複数の非推奨APIが削除されたため、これらを利用しているプロジェクトがコンパイルエラーとなります。

[手順が必要なケース]

Apache POIを利用し、かつ、3.17で削除されたAPIを利用している場合

[修正方法]

代替APIを利用するように修正してください。 修正方法は、Apache POI 3.16のJavadocをダウンロード・解凍し、「Deprecated API」（deprecated-list.html）をご参照ください。

共通ライブラリが管理するGuavaのバージョンが20.0から27.0.1-jreになりました。

アプリケーションで利用しているライブラリがGuavaに依存しており、27.0.1-jreでは正常に動作しない場合、 pomファイルでguava.versionプロパティを定義することで、任意のバージョンを指定して利用することが可能です。

例として、Selenium 3.0.1を利用する場合、一部のメソッドについてGuava 27.0.1-jreでは正常に動作せず、20.0で正常に動作することを確認しています。 これは、古いブラウザでE2Eテストを実施しており、Seleniumをspring-boot-dependenciesで管理する3.14.0にアップグレードできない場合の一例になります。

ただし、spring-boot-dependencies及び、共通ライブラリで管理されていないバージョンを利用する場合はアプリケーションの動作に影響がないことを、開発プロジェクトにて十分に動作検証を行ってください。

[手順が必要なケース]

• 利用しているライブラリがGuava 27.0.1-jreでは正常に動作しない場合。

[修正方法]

pomファイルにguava.versionプロパティを追加し、使用するバージョンを指定してください。

• pom.xmlの定義例

<properties>
    <!-- omitted -->
    <guava.version>20.0</guava.version> <!-- ### 追加箇所 ### -->
    <!-- omitted -->
</properties>

terasoluna-gfw-common に新規コードリスト SimpleReloadableI18nCodeList を追加いたしました。

SimpleReloadableI18nCodeList は国際化に対応した SimpleI18nCodeList をリロード可能としたものになります。 JdbcCodeList を内包する SimpleI18nCodeList を利用している場合は SimpleReloadableI18nCodeList に変更することで、 アプリケーションを再起動することなくコードリストのリロードが可能となります。

[手順が必要なケース]

この手順の適用は任意です。JdbcCodeList を内包する SimpleI18nCodeList を利用している場合は、必要に応じて次の修正を行ってください。

[修正方法]

Bean定義ファイルのクラス名 SimpleI18nCodeList を SimpleReloadableI18nCodeList に変更します。

【修正前】

<bean id="CL_I18N_PRICE"
    class="org.terasoluna.gfw.common.codelist.i18n.SimpleI18nCodeList">
    <property name="rowsByCodeList">
        <util:map>
            <entry key="en" value-ref="(en用JdbcCodeListのID)" />
            <entry key="ja" value-ref="(ja用JdbcCodeListのID)" />
        </util:map>
    </property>
</bean>

【修正後】

<bean id="CL_I18N_PRICE"
    class="org.terasoluna.gfw.common.codelist.i18n.SimpleReloadableI18nCodeList">
    <property name="rowsByCodeList">
        <util:map>
            <entry key="en" value-ref="(en用JdbcCodeListのID)" />
            <entry key="ja" value-ref="(ja用JdbcCodeListのID)" />
        </util:map>
    </property>
</bean>

コードリストの更新方法については、開発ガイドラインのコードリストをリロードする場合を参照してください。

入力された値がコードリストに定義されていることを検証する @ExistInCodeList で、Number 型（ Integer 型や Long 型など）のフィールドを検証できるよう改善されました。

従来の @ExistInCodeList では検証可能な型が Character 型および CharSequence 型のみであったため、 数値の入力を受け付けるFormオブジェクトのフィールドであっても String 型とせざるを得ない場合がありましたが、 今回の改善により適切な型のフィールドを定義することが可能となります。

[手順が必要なケース]

この手順の適用は任意です。以下のケースに当てはまる場合、必要に応じて修正を行ってください。

• 従来の @ExistInCodeList で検証するために、数値の入力を受け付けるFormオブジェクトのフィールドを String 型等にしている場合。

[修正方法]

Formオブジェクトの String 型フィールドを適切な型に変更し、必要に応じて String 型から適切な型への変換ロジックを削除します。

【修正前】

• Formオブジェクト

public class SampleForm {

    @ExistInCodeList(codeListId = "CL_MONTH")
    private String month;

    // ommited getter and setter
}

• Controller

@RequestMapping
public String handle(@Valid SampleForm form, BindingResult result) {

    Integer month = Integer.valueOf(form.getMonth());

    // ommited logics
}

【修正後】

• Formオブジェクト

public class SampleForm {

    @ExistInCodeList(codeListId = "CL_MONTH")
    private Integer month;

    // ommited getter and setter
}

• Controller

@RequestMapping
public String handle(@Valid SampleForm form, BindingResult result) {

    Integer month = form.getMonth();

    // ommited logics
}

開発ガイドラインのコードリストを独自カスタマイズする方法の実装例が修正されました。

以前の実装例では @Component を用いてコードリストをコンポーネント登録していましたが、コードリストのBean定義を xxx-codelist.xml に集約するため、定義方法が修正されました。

[手順が必要なケース]

この手順の適用は任意です。独自カスタマイズしたコードリストを実装している場合は、必要に応じて次の修正を行ってください。

[修正方法]

独自カスタマイズしたコードリストから @Component を削除し、xxx-codelist.xml でBean定義を行うように変更してください。 また、 @Inject を利用してインジェクションを行っている場合は、フィールドの Setter を定義し、Bean定義の property タグを利用するように変更してください。

【修正前】

• 独自カスタマイズしたコードリストの実装例

@Component("CL_YEAR")
public class DepYearCodeList extends AbstractCodeList {

    @Inject
    JodaTimeDateFactory dateFactory;

    // omitted

}

【修正後】

• 独自カスタマイズしたコードリストの実装例

public class DepYearCodeList extends AbstractCodeList {

    private JodaTimeDateFactory dateFactory;

    public void setDateFactory(JodaTimeDateFactory dateFactory) {
        this.dateFactory = dateFactory;
    }

    // omitted

}

• xxx-codelist.xml の定義例

<bean id="CL_YEAR" class="com.example.sample.domain.codelist.DepYearCodeList">
    <property name="dateFactory" ref="dateFactory" />
</bean>

terasoluna-gfw-validator に新規制約アノテーション @ByteSize を追加いたしました。

@ByteMin と @ByteMax を併用してバイト長の範囲チェックを行っている場合は、@ByteSize を利用することでパフォーマンスの向上が期待できます。

[手順が必要なケース]

この手順の適用は任意ですが、次のケースに当てはまる場合は、修正を行うことを推奨します。

• @ByteMin と @ByteMax を併用してバイト長の範囲チェックを行っている場合。

[修正方法]

@ByteMin と @ByteMax を @ByteSize に変更します。

【修正前】

public class SampleForm {

    @ByteMin(10)
    @ByteMax(20)
    private String target;

    // ommited getter and setter
}

【修正後】

public class SampleForm {

    @ByteSize(min = 10, max = 20)
    private String target;

    // ommited getter and setter
}

なお、この変更に併せて、@ByteMin と @ByteMax で value 属性（最小/最大バイト数）に不正な値を設定した場合には 実行時に IllegalArgumentException がスローされるよう変更されました。

この場合、元々作りこまれていたプログラムバグが顕在化した形になりますので、必ず設定値の見直しを行ってください。

ブランクプロジェクトの<mvc:interceptor>の定義から、.htmlで終わるパスを対象外とする設定が削除されました。

これはWebアプリ内の静的リソースであるHTMLファイルに対してインターセプターを適用しないための設定でしたが、静的リソースには機能していないことが判明したためです。

この変更により、リクエストパスに.htmlを付与した場合も正常にインターセプターが適用されるようになりました。

[手順が必要なケース]

この手順の適用は必須です。

[修正方法]

spring-mvc.xmlに定義されている全ての<mvc:interceptor>から、<mvc:exclude-mapping path="/**/*.html" />を削除してください。

• spring-mvc.xmlの定義例

<mvc:interceptors>

    <!-- omitted -->

    <mvc:interceptor>
        <mvc:mapping path="/**" />
        <mvc:exclude-mapping path="/resources/**" />
        <mvc:exclude-mapping path="/**/*.html" /> <!-- ### 削除箇所 ### -->
        <!-- omitted -->
    </mvc:interceptor>

    <!-- omitted -->

</mvc:interceptors>

TERASOLUNA Server Framework for Javaでは5.5.1から、OWASP(Open Web Application Security Project)で推奨されるPBKDF2アルゴリズムの使用を推奨しています。

ブランクプロジェクトの5.5.1からは、PasswordEncoderをPBKDF2アルゴリズムを使用する形に変更しました。

現在利用しているPasswordEncoderから、Pbkdf2PasswordEncoderに移行することを推奨します。

[手順が必要なケース]

この手順の適用は任意です。必要に応じて、次の修正を行ってください。

[修正方法]

ブランクプロジェクトのapplicationContext.xmlに定義されているBCryptPasswordEncoderをPbkdf2PasswordEncoderに移行する場合、以下のように書き換えてください。

【修正前】

<bean id="passwordEncoder" class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" />

【修正後】

<bean id="passwordEncoder" class="org.springframework.security.crypto.password.Pbkdf2PasswordEncoder" />

既存のPasswordEncoderでハッシュ化したパスワードは、変更後のPbkdf2PasswordEncoderでは照合することができません。また、ハッシュ化は暗号化と異なりハッシュ化されたパスワードを複合することもできません。

セキュリティ向上のためパスワードのハッシュ化にPbkdf2PasswordEncoderを利用したいが、既存のPasswordEncoderでハッシュ化したパスワードも利用し続ける必要がある場合は、次節で説明を行うDelegatingPasswordEncoderの適用を検討してください。

[備考]

デフォルト設定のPbkdf2PasswordEncoderはBCryptPasswordEncoderに比べ、イテレーション回数が多くパフォーマンスが低下します。

詳細はPbkdf2PasswordEncoderのカスタマイズを参照してください。

Spring Security 5.0 よりorg.springframework.security.crypto.password.DelegatingPasswordEncoderが追加されました。 DelegatingPasswordEncoderはハッシュ値の照合の際に、対応するPasswordEncoderに処理を委譲します。 ハッシュ値の照合に複数のPasswordEncoderを使用できるようになるため、別々のPasswordEncoderでハッシュ化されたパスワードを管理することが容易になります。

PasswordEncoderの移行を行う際には、移行前後のPasswordEncoderでの照合に対応するためのアプリケーションの実装や、移行後のPasswordEncoderでハッシュ化しなおすための既存パスワードの初期化が不要となるため、 DelegatingPasswordEncoderを利用することを推奨します。

[手順が必要なケース]

この手順の適用は任意ですが、次のケースに当てはまる場合は、修正を行うことを推奨します。

• 前述の「[Step 15] 推奨するPasswordEncoder（アルゴリズム）の変更」によりPbkdf2PasswordEncoderへの移行を行う場合。
• 後述の「[Step 17] 非推奨アルゴリズムのPasswordEncoderが廃止されたことに伴う修正」によりMessageDigestPasswordEncoderへの移行を行う場合。

また、上記ケースに当てはまらない場合についても将来的に使用するPasswordEncoder（アルゴリズム）の変更を考慮して、直近でPasswordEncoderの移行を行わない場合でもDelegatingPasswordEncoderを利用することを推奨します。

[修正方法]

ブランクプロジェクトのapplicationContext.xmlに定義されているBCryptPasswordEncoderをPbkdf2PasswordEncoderに移行する際に、DelegatingPasswordEncoderを利用する場合は以下のように書き換えてください。

【修正前】

<bean id="passwordEncoder" class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" />

【修正後】

<bean id="passwordEncoder" class="org.springframework.security.crypto.password.DelegatingPasswordEncoder">
    <constructor-arg name="idForEncode" value="pbkdf2" />
    <constructor-arg name="idToPasswordEncoder">
        <map>
            <entry key="pbkdf2">
                <bean class="org.springframework.security.crypto.password.Pbkdf2PasswordEncoder" />
            </entry>
        </map>
    </constructor-arg>
    <property name="defaultPasswordEncoderForMatches">
        <bean class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" />
    </property>
</bean>

DelegatingPasswordEncoderを利用すると、ハッシュ化に利用したPasswordEncoderの識別子が付与されるためハッシュ値が長くなります。 また、PasswordEncoderの変更によってもハッシュ値が移行前より長くなる場合があるため、データベースでは適宜カラムサイズを変更する必要があります。

詳細については、開発ガイドラインのDelegatingPasswordEncoderを参照してください。

Spring Security 5.0 からorg.springframework.security.authentication.encoding.PasswordEncoderが廃止されました。 廃止されたPasswordEncoderは固定のソルトを使用しますが、Spring Security 5 では固定のソルトを使用するPasswordEncoderは提供されなくなりました。 固定のソルトを使用し続けることはセキュリティ上のリスクが伴うことから、ランダムなソルトを使用するorg.springframework.security.crypto.password.PasswordEncoderに移行することを推奨します。

使用するハッシュ化アルゴリズムに制約が存在しない場合は前々節で紹介したPbkdf2PasswordEncoderに移行することを推奨します。 ハッシュ化アルゴリズムの制約が存在し、SHA-1やSHA-256、MD5等を使用しなくてはいけない場合はMessageDigestPasswordEncoderを使用してください。

[手順が必要なケース]

Spring Security 5.0 で廃止になった非推奨アルゴリズムのorg.springframework.security.authentication.encoding.PasswordEncoder（ShaPasswordEncoder等）を利用している場合。

[修正方法]

廃止になった非推奨アルゴリズムのPasswordEncoderの代替として、MessageDigestPasswordEncoder（org.springframework.security.crypto.password.PasswordEncoderの実装クラス）を使用します。

org.springframework.security.crypto.password.PasswordEncoderの実装クラスはソルトがランダムに決まる仕様であるため、ソルトを指定することはできません。 生成されたソルトは以下のフォーマットでハッシュ値の前に付与されます。

{salt}hashValue

5.4.1版開発ガイドラインのShaPasswordEncoderの利用の実装から移行する場合は、以下のように書き換えます。

MessageDigestPasswordEncoderをapplicationContext.xmlにBean定義してください。

【修正前】

<bean id ="passwordEncoder"
    class="org.springframework.security.authentication.encoding.ShaPasswordEncoder">
    <constructor-arg value="512" />
    <property name="iterations" value="1000" />
</bean>

【修正後】

<bean id="passwordEncoder"
    class="org.springframework.security.crypto.password.MessageDigestPasswordEncoder">
    <constructor-arg name="algorithm" value="SHA-512" />
    <property name="iterations" value="1000" />
<bean>

spring-security.xmlの定義を以下のように修正します。

【修正前】

<bean id="authenticationProvider"
    class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
    <!-- omitted -->
    <property name="saltSource" ref="saltSource" />
    <property name="userDetailsService" ref="userDetailsService" />
    <property name="passwordEncoder" ref="passwordEncoder" />
</bean>

<bean id="saltSource"
    class="org.springframework.security.authentication.dao.ReflectionSaltSource">
    <property name="userPropertyToUse" value="username" />
</bean>

【修正後】

<bean id="authenticationProvider"
    class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
    <!-- omitted -->
    <property name="userDetailsService" ref="userDetailsService" />
    <property name="passwordEncoder" ref="passwordEncoder" />
</bean>

既に固定のソルトでハッシュ化されたパスワードに対応するため、UserDetailsに以下の処理を追加します。

パスワードにソルトが付与されていない（文字列の先頭が{でない）場合は、ソルトをパスワードの先頭に付与します。

• UserDetailsの実装クラスへの処理の追加例

public class AccountUserDetails implements UserDetails {

    private final Account account;
    private final Collection<GrantedAuthority> authorities;

    public AccountUserDetails(Account account,
            Collection<GrantedAuthority> authorities) {
        this.account = account;
        this.authorities = authorities;
    }

    public String getPassword() {
        // 追加箇所 開始
        if(!account.getPassword().startsWith("{")){
            return "{" + getUsername() + "}" + account.getPassword();
        }
        // 追加箇所 終了
        return account.getPassword();
    }

    public String getUsername() {
        return account.getUsername();
    }

    // ommited

}

MessageDigestPasswordEncoderはハッシュ化したパスワードにソルトを付与するため、ハッシュ値が移行前より長くなります。 データベースでは適宜カラムサイズを変更する必要があります。

詳細については、開発ガイドラインのMessageDigestPasswordEncoderの利用を参照してください。

開発ガイドラインのJMSの実装例にて、Bean定義を記載するファイルの整理が行われました。

[手順が必要なケース]

この手順の適用は任意ですが、以下のケースに当てはまる場合は、次の修正を行うことを推奨します。

• JMSについて、開発ガイドラインに準拠した実装を行っている。

[修正方法]

各定義を記載するBean定義ファイルが以下のように変更されました。

.. tabularcolumns:: |p{0.30\linewidth}|p{0.30\linewidth}

また、 ConnectionFactory をアプリケーションサーバで定義を行う場合についても、定義箇所は上記表のとおり [projectName]-infra.xml から [projectName]-env.xml に変更が行われました。

[備考]

開発環境と本番環境で異なるMQ製品を使用し、Bean定義の設定が環境ごとに異なる場合は、開発ガイドライン通りに定義を行えない場合があります。 jms:listener-container等の一部のBean定義は、プロパティプレースホルダで設定を置き換えすることができないため、 [projectName]-env.xml に定義を行いMavenのプロファイルを用いて設定を切り替える必要があります。

ブランクプロジェクトのpomファイルで、 PostgreSQL JDBC Driver と Oracle JDBC のバージョン定義を更新しました。

これらのJDBCドライバーは上位互換性が保障されているため、最新バージョンを使用することを推奨します。

[手順が必要なケース]

この手順の適用は任意ですが、次のケースに当てはまる場合は、修正を行うことを推奨します。

• PostgreSQL 8.2以降のバージョンを使用している。
• Oracle Database 11.1以降のバージョンを使用している。

[修正方法]

【PostgreSQLを使用する場合】

pomファイルのプロパティを修正してください。

• pom.xml

<properties>
    <!-- omitted -->
    <postgresql.version>42.2.5</postgresql.version> <!-- ### 修正箇所 ### -->
    <!-- omitted -->
</properties>

【Oracle Databaseを使用する場合】

pomファイルのojdbcのdependency定義とプロパティを修正してください。 設定はOracle Maven Repositoryに準拠しています。

• pom.xml

<dependencyManagement>
    <dependencies>
    <!-- omitted -->
        <dependency>
            <groupId>com.oracle.jdbc</groupId>
            <artifactId>ojdbc8</artifactId>>  <!-- ### 修正箇所 ### -->
            <version>${ojdbc.version}</version>
        </dependency>
    <!- omitted -->
    </dependencies>
</dependencyManagement>

<properties>
    <!-- omitted -->
    <ojdbc.version>18.3</ojdbc.version> <!-- ### 修正箇所 ### -->
    <!-- omitted -->
</properties>

Spring Framework 5.0.2以前ではiText 2.1.7をサポートしていましたが、後継のiText 5.0.0よりAGPLライセンスに変更されたため、 Spring Framework 5.0.3以降ではiTextからフォークされたOpenPDF（LGPL 3.0とMPL 2.0のデュアルライセンス）をサポートしています。

TERASOLUNA Server Framework for Javaも上記変更に準拠し、5.5.1以降ではOpenPDFをサポートしています。

OpenPDFでは、iText 2.1.7からいくつかのバグや脆弱性が修正されています。

なお、5.4.1以前のitext 2.1.7から依存ライブラリの除外を行っていた設定につきましては、本来不要な設定であったため、今回併せて修正しています。

[手順が必要なケース]

iTextを利用している場合。

[修正方法]

以下のようにpomファイルの依存関係を変更してください。

【修正前】

<dependencies>
    <!-- omitted -->
    <dependency>
        <groupId>com.lowagie</groupId>
        <artifactId>itext</artifactId>
        <exclusions>
            <exclusion>
                <artifactId>xml-apis</artifactId>
                <groupId>xml-apis</groupId>
            </exclusion>
            <exclusion>
                <artifactId>bctsp-jdk14</artifactId>
                <groupId>org.bouncycastle</groupId>
            </exclusion>
            <exclusion>
                <artifactId>jfreechart</artifactId>
                <groupId>jfree</groupId>
            </exclusion>
            <exclusion>
                <artifactId>dom4j</artifactId>
                <groupId>dom4j</groupId>
            </exclusion>
            <exclusion>
                <groupId>org.swinglabs</groupId>
                <artifactId>pdf-renderer</artifactId>
            </exclusion>
            <exclusion>
                  <groupId>org.bouncycastle</groupId>
                  <artifactId>bcprov-jdk14</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.bouncycastle</groupId>
        <artifactId>bcprov-jdk14</artifactId>
        <version>1.38</version>
    </dependency>
</dependencies>

【修正後】

<dependencies>
    <!-- omitted -->
    <dependency>
        <groupId>com.github.librepdf</groupId>
        <artifactId>openpdf</artifactId>
    </dependency>
</dependencies>

なお、iText 2.1.7を利用する場合、日本語の出力を行うためにはiTextAsianを依存ライブラリに追加する必要がありましたが、 OpenPDFはデフォルトで日本語に対応しているため、追加している場合、pomファイルから依存関係の削除が必要になります。

iTextAsianはMaven Central Repositoryで公開されないライブラリであり、各開発プロジェクトで参照するための対応を行っていると思われます。 これらの設定も不要となるため、併せて見直してください。

以下は利用方法の一例になります。

• maven-install-pluginを利用してアプリケーションのビルド時にローカルリポジトリにインストールしている場合、その設定が不要となります。
• Nexus等のリポジトリやファイルサーバーで公開している場合、公開は不要となります。

Spring Framework 5よりJasperReportsがサポート対象外となりました。

以下のパッケージのクラス（Spring FrameworkとJasperReportsの連携クラス）が削除されたため、これらを利用しているプロジェクトがコンパイルエラーとなります。

• org.springframework.ui.jasperreports
• org.springframework.web.servlet.view.jasperreports

JasperReportsを継続して使用するためには、上記に相当するクラスを独自に実装する必要があります。

[手順が必要なケース]

JasperReportsCsvView等のSpring FrameworkとJasperReportsとの連携クラスを使用している場合。

[修正方法]

JasperReportsを継続して使用するためには、上記に相当するクラスを独自に実装する必要があります。

なお推奨はいたしませんが、Spring Framework 4.3.14.RELEASEで提供される 上記のパッケージのソースコードをコピーしてプロジェクト上に配置することで、今まで通りJasperReportsを利用できることを確認しています。 （検証ではCSVファイルのダウンロードができることを確認しています。）

移行に際しては、プロジェクトチームの責任の下、十分な回帰試験を実施するようお願いいたします。 また、Spring Frameworkのソースコードを流用される場合は、ソフトウェアライセンスに基づき適切な対応を行ってください。

[備考]

Spring Framework 5より、同様にVelocityもサポート対象外となりました。

Spring Data 2.0からCrudRepositoryのメソッドシグネチャが変更されました。 この変更では、Java 8で導入された Optional への対応と、メソッド命名規則の変更が行われました。

開発ガイドラインでは、メソッド名はSpring Data 1.0の命名規則に準拠したものを記載し、JPAに関わる実装のみSpring Data 2.0に対応しています。

[手順が必要なケース]

以下のケースと全て一致する場合は、次の変更を行ってください。

• データべースアクセスにJPAを利用している。
• CrudRepositoryを利用している。

CrudRepositoryを継承するクラスを利用する場合についても修正が必要になります。 一覧については開発ガイドラインのSpring Data提供のインタフェースを継承するを参照してください。

また、@NoRepositoryBeanか@RepositoryDefinitionを付与したRepositoryインタフェースでは、CrudRepositoryの任意のメソッドを暗黙的に実装することができます。 これらのクラスを利用している場合は影響の有無を確認し、必要に応じて修正を行ってください。

[修正方法]

対象のRepositoryインタフェースのメソッドを以下の表に従い修正してください。 対象のRepositoryを利用するService等も同様に修正する必要があります。

.. tabularcolumns:: |p{0.30\linewidth}|p{0.30\linewidth}

なお、findByIdメソッドは戻り値型がOptionalとなるため、Service等のロジックでOptionalを適切にハンドリングする必要があります。 OptionalのJavadoc等を参考に対応してください。

Spring Framework 4.2から非推奨となっていたorg.springframework.web.servlet.view.document.AbstractExcelViewが、Spring Framework 5.0で廃止となりました。 AbstractExcelViewを利用している場合、コンパイルエラーとなります。

[手順が必要なケース]

AbstractExcelViewを利用している場合、この手順の適用は必須です。

[修正方法]

AbstractExcelViewの代わりに org.springframework.web.servlet.view.document.AbstractXlsView等を利用するように変更してください。

AbstractXlsViewはAbstractExcelViewと同じくXLS形式のExcelファイルに対応するクラスになります。 使用するExcelファイルをXLSX形式に変更できる場合は、AbstractXlsxViewに移行することを推奨します。

Spring Framework 5より、SpringのコアAPIにnull-safetyの機能が取り入れられ、 SpELが解釈される際のnullに対する動作も変更(SPR-15540)されました。

これにより、SpELが解釈した値がnullとなった場合、従来とは異なる動きをする場合があります。

例えば、Mapから値を取得するSpELでキー値にnullとなる値を入力すると、 Spring Framework 4以前ではそのままMapにnullが渡され該当する値がないためnullが返却されていましたが、 Spring Framework 5以降ではキーとなるSpELを評価した結果に対するnullチェックが追加されており、nullの場合はIllegalStateExceptionが発生するようになりました。

[手順が必要なケース]

SpELを利用し、かつ、nullを考慮した実装を行っていない場合

[修正方法]

Mapを利用するSpELではキーとする値に対して事前にnullチェックを行うなど、nullを考慮した実装になるように修正を行ってください。

例えば以下のような実装を行っていた場合、departmentCodeがnullでないことをチェックするように修正してください。

【修正前】

@PreAuthorize("#employee.department[#account.departmentCode] == '人事部'")
public User getUserInformation(Employee employee, Account account) {
    // omitted
}

【修正後】

@PreAuthorize("#account.departmentCode != null && #employee.department[#account.departmentCode] == '人事部'")
public User getUserInformation(Employee employee, Account account) {
    // omitted
}

Spring Framework 5.0より、JMS 2.0がサポートされました。 JMS 1.1との後方互換性も維持されているため、JMS 1.1で動作させることも可能ですが、JMS 1.1で動作させる場合でも、JMS 2.0のAPIをクラスパスに追加する必要があります。

詳細は、spring-projects/spring-framework/issues/#18366を参照してください。

[手順が必要なケース]

以下の全てに当てはまる場合は対応が必要です。

• Spring JMSを利用している場合
• アプリケーションサーバがJMS 2.0に対応しておらず、JMS API 2.0のライブラリを持たない場合

[修正方法]

アプリケーションに追加する場合は、JMS 2.0のAPIを依存関係に追加します。

• pom.xml

<dependencies>
    <!-- ### 追加箇所 開始 ### -->
    <dependency>
        <groupId>javax.jms</groupId>
        <artifactId>javax.jms-api</artifactId>
        <scope>runtime</scope>
    </dependency>
    <!-- ### 追加箇所 終了 ### -->

    <!-- omitted -->

</dependencies>

Spring 5.0より、アップロードされたファイルやマルチパートのリクエストが指定サイズを超過した場合に、MultipartExceptionのサブクラスのMaxUploadSizeExceededExceptionをスローするように改善されました。

ただし、本改善ではAPサーバがスローしたサイズ超過等の例外のメッセージに応じてMultipartExceptionとするかMaxUploadSizeExceededExceptionを決定しており、APサーバの実装によっては超過であっても 従来通りMultipartExceptionをスローします。 Tomcat 9.0.10およびWebLogic 12.2.1.3において、MaxUploadSizeExceededExceptionとなることを確認しています。

MultipartExceptionについては、開発ガイドラインのファイルアップロードの例外ハンドリング設定を参照してください。

[手順が必要なケース]

この手順の適用は任意です。以下のすべてと一致する場合は、次の実装を行ってください。

• 使用するAPサーバで、アップロードされたファイルやマルチパートのリクエストが指定サイズを超過した例外がMaxUploadSizeExceededExceptionに解釈される。
• 業務仕様上、アップロードされたファイルやマルチパートのリクエストのサイズ超過とその他の例外を区別する必要がある。

なお、利用するAPサーバでMaxUploadSizeExceededExceptionに解釈されるかどうかは、動作検証していただくか各ベンダーにお問い合わせください。

[備考]

サイズ超過とその他の例外を区別する必要がない場合でも、発生する例外がMultipartExceptionからMaxUploadSizeExceededExceptionになることによる影響がないか確認をおこなってください。

[実装方法]

MultipartExceptionの例外ハンドリングを行っている箇所で、同様にMaxUploadSizeExceededExceptionをハンドリングするよう変更してください。

• MiltipartFilter使用時の実装例

error-page要素は上から順に評価されるため、MaxUploadSizeExceededExceptionはMultipartExceptionの前に追加してください。

<!-- ### 追加箇所 開始 ### -->
<error-page>
    <exception-type>org.springframework.web.multipart.MaxUploadSizeExceededException</exception-type>
    <location>/WEB-INF/views/common/error/fileUploadSizeOverError.jsp</location>
</error-page>
<!-- ### 追加箇所 終了 ### -->

<error-page>
    <exception-type>org.springframework.web.multipart.MultipartException</exception-type>
    <location>/WEB-INF/views/common/error/fileUploadError.jsp</location>
</error-page>

• MiltipartFilterを使用しない場合の実装例

SimpleMappingExceptionResolverのexceptionMappingsプロパティに指定した例外は上から順に評価されるため、MaxUploadSizeExceededExceptionはMultipartExceptionの前に追加してください。

<bean class="org.terasoluna.gfw.web.exception.SystemExceptionResolver">
    <!-- omitted -->
    <property name="exceptionMappings">
        <map>
            <!-- omitted -->
            <entry key="MaxUploadSizeExceededException"
                   value="common/error/fileUploadSizeOverError" />  <!-- ### 追加箇所 ### -->
            <entry key="MultipartException"
                   value="common/error/fileUploadError" />
        </map>
    </property>
    <property name="statusCodes">
        <map>
            <!-- omitted -->
            <entry key="common/error/fileUploadSizeOverError" value="400" />  <!-- ### 追加箇所 ### -->
            <entry key="common/error/fileUploadError" value="400" />
        </map>
    </property>
    <!-- omitted -->
</bean>

開発ガイドラインのMybatis3を使用したEntityの検索処理に、ページネーション検索の結果をソートする 実装例が追加されました。

この実装例では Pageable オブジェクトの sort プロパティを利用して、SQLで検索結果のソートを行います。

[手順が必要なケース]

この手順の適用は任意ですが、以下のケースに当てはまる場合は、次の修正を行うことを推奨します。

• Mybatis3を使用したページネーション検索で、SQLでのソートを独自に実装している。

[修正方法]

開発ガイドラインの実装例を確認し、実装を修正してください。

MyBatis3で Pageable オブジェクトを利用した検索結果のソートを行う場合、ソート条件は置換変数を使用して埋め込む必要があるため、SQL Injectionが発生する可能性があります。 独自の実装を行っている場合は特に、SQL Injectionを考慮し適切に対策が行われているかの確認を行ってください。

詳細はSQL Injection対策を参照してください。

Spring Security 5 からorg.springframework.security.crypto.codec.Base64が非推奨となりました。 そのため、Java 8 から導入されたjava.util.Base64を使用することを推奨します。

[手順が必要なケース]

org.springframework.security.crypto.codec.Base64を使用している。

[修正方法]

以下の例を参考にimport文、メソッドを修正してください。

【修正前】

import org.springframework.security.crypto.codec.Base64;

// ommited

public byte[] encode(byte[] src){

    return new Base64.encode(src);

}

public String encodeToString(byte[] src){

    return new String(Base64.encode(src));

}

public byte[] decode(byte[] src){

    return new Base64.decode(src);

}

【修正後】

import java.util.Base64;

// ommited

public byte[] encode(byte[] src){

    return Base64.getEncoder().encode(src);

}

public String encodeToString(byte[] src){

    return Base64.getEncoder().encodeToString(src);

}

public byte[] decode(byte[] src){

    return Base64.getDecoder().decode(src);

}

Spring Security OAuth 2.2.2 より、リダイレクトURIのホワイトリストチェックの仕様が変更されました。

クライアントが認可リクエスト時に申告するリダイレクトURIについて、2.2.1以前では認可サーバに登録されたリダイレクトURIのパス配下であることを確認していましたが、2.2.2ではパスと完全一致することを確認するようになりました。 そのため、認可サーバにはリダイレクトするすべてのパスを登録する必要があります。

[手順が必要なケース]

リダイレクトURIのホワイトリストに登録されているパスがリダイレクトするパスと完全一致していない場合。

[修正方法]

リダイレクトURIのホワイトリストに、リダイレクトするすべてのパスを登録するように修正してください。

開発ガイドラインの クライアントの認証 に準拠した実装の場合は、認証パラメータを管理するDBのテーブルにリダイレクトURIのレコードを追加してください。

Spring Securityのセキュリティヘッダを書き込むHeaderWriterFilterにおいて、 Spring Security 4.2.4では、フィルタ実行時（リクエスト受付時）にセキュリティヘッダの書き込みを行っていましたが、 Spring Security 5.0.2以降ではレスポンスのコミットまたはインクルード時にセキュリティヘッダの書き込みを行うよう変更されました。 これにより、Controller等の処理より後にセキュリティヘッダが書き込まれるようになりました。

この変更により、「Spring Securityによって必ずCache-Controlヘッダが書き込まれることにより、Controller等で書き込んだ同ヘッダが有効にならない事象」が解決されました。

ただし、この変更は不完全であり、Cache-Controlヘッダとそれ以外のセキュリティヘッダにより動作が異なります。

• Cache-Controlヘッダ

  レスポンスのコミットまたはインクルード時にCache-Controlヘッダがない場合、Spring SecurityによってCache-Controlヘッダが書き込まれます。

  Controller等で同ヘッダが書き込まれた場合は、Spring Securityによる書き込みは行われません。

• Cache-Controlヘッダ以外

  レスポンスのコミットまたはインクルード時にSpring Securityによって必ず該当のセキュリティヘッダが書き込まれます。

  Controller等で同ヘッダが書き込まれた場合は、従来と同様に重複するがその順序が異なります。

詳細は、開発ガイドラインの セキュリティヘッダの選択の Warning「個別に付与したセキュリティヘッダがSpring Securityにより上書き（追加）される問題」をご参照ください。

また、この変更はDelegatingRequestMatcherHeaderWriterの動作に大きく影響します。

具体的には、DelegatingRequestMatcherHeaderWriterが委譲するRequestMatcherによるリクエストパスの判定は、セキュリティヘッダの書き込み時に行われます。 このタイミングが変更されたことにより、リクエストがフォワードされた場合、リクエストパスが変更され意図した通りにリクエストパスの判定が行われなくなりました。

以下に、それぞれの詳細と修正方法を解説します。

以下の２点の影響があります。

• ユースケースごとに異なるキャッシュ制御が可能になった

  Controller等でCache-Controlヘッダが書き込まれた場合は、Spring Securityによる書き込みが行われなくなりました。

  これにより、ユースケースごとに異なるキャッシュ制御が可能になりました。

• SystemExceptionResolverのpreventResponseCachingプロパティと併用した場合の挙動が変更された

  SystemExceptionResolverのpreventResponseCachingプロパティとSpring SecurityのCache-Controlヘッダを併用した場合、SystemExceptionResolverが有効になるようになりました。

  これにより、例外時のみ異なるキャッシュ制御が行われるようになります。

このうち、後者のSystemExceptionResolverについては移行上の問題となるケースがあるので、対策することを推奨します。

[手順が必要なケース]

以下の全てに当てはまる場合は対応が必要です。

• Spring SecurityのCache-Controlヘッダを有効にしている
• SystemExceptionResolverのpreventResponseCachingプロパティを有効（true）にしている

[修正方法]

• SystemExceptionResolverのpreventResponseCachingプロパティを無効（false）にします。 開発ガイドラインの HTTPレスポンスのキャッシュ制御有無をご参照ください。

Spring Securityが書き込むセキュリティヘッダと同ヘッダがControllerやViewで書き込まれた場合は、従来と同様に重複しますがその順序が異なります。 これにより、ブラウザで異なる解釈をされ挙動が変更される可能性があります。

また、このレスポンスを受け取るクライアントアプリケーションやテストコードでも、順序の変更に対応する必要がある場合があります。

[手順が必要なケース]

以下の全てに当てはまる場合は対応が必要です。

• Spring Securityのセキュリティヘッダを有効にしている
• 同ヘッダをControllerやViewで書き込んでいる

[修正方法]

クライアントアプリケーションやテストコードのうち、セキュリティヘッダを参照している箇所を見直します。

[備考]

通常、同一のヘッダを重複登録しないよう設計すべきですが、 重複登録されるヘッダの順序変更による影響を許容できない場合は、後述の「Spring Security 4.2.4の実装に戻す方法」による対応もご検討ください。

具体的には、DelegatingRequestMatcherHeaderWriterが委譲するRequestMatcherによるリクエストパスの判定は、セキュリティヘッダの書き込み時に行われます。 このタイミングが変更されたことにより、リクエストがフォワードされた場合、リクエストパスが変更され意図した通りにリクエストパスの判定が行われなくなりました。

特にTilesを使用するアプリケーションでは、Tilesによりリクエストがフォワードされるため、DelegatingRequestMatcherHeaderWriterが正常に動作しなくなる場合があります。 詳細は、開発ガイドラインの リクエストパターン毎のセキュリティヘッダの出力の Warning「指定したパスが意図した通りに認識されない問題」をご参照ください。

[手順が必要なケース]

DelegatingRequestMatcherHeaderWriterを利用してリクエストのパターン毎にセキュリティヘッダの出力を制御しており、以下のいずれかに当てはまる場合は対応が必要です。

• Controllerでリクエストのフォワード（返却値にforward:を付与）を行っている
• JSPでリクエストのフォワード（jsp:forwardタグ等を利用）を行っている
• Tilesを使用し、Tilesによりリクエストがフォワードされている
• 上記以外に任意のフォワードを行っている

上記のうち、Tilesは扱うJSPの容量により、フォワードされる場合とされない場合があることを確認しています。

[修正方法]

以下のいずれかの修正を行います。

• HeaderWriterFilterとDelegatingRequestMatcherHeaderWriterを独自に実装し、フィルタ実行時にリクエストパスを判定する。
• DelegatingRequestMatcherHeaderWriterが委譲するRequestMatcherを拡張し、フォワード元のリクエストパスを判定する。

詳細は、 spring-security#6338を参照ください。

なお、上記の方法はTERASOLUNA Server Framework for Javaとして動作を保証するものではありません。 開発プロジェクトにおいて十分な動作検証を行ってください。

推奨いたしませんが、上記の変更および対策が許容されない場合、 移行前のバージョンに準拠したHeaderWriterFilterを独自に実装することで、移行前のバージョンの動作を再現することが可能です。

実装方法は、 5.3.2の開発ガイドラインのセキュリティヘッダの選択の Warning「アプリケーションサーバによってはCache-Controlヘッダが正しく設定されない問題」をご参照ください。

Spring Security 4.2.4のHeaderWriterFilterについては、 HeaderWriterFilter.javaを参照ください。

期待する動作となるかどうか、開発プロジェクトにおいて十分な動作検証を行ってください。

Hibernate 5.2.12より関連EntityのLazy Loadにおけるロードタイミングが改善されました。 この変更により、キー項目（@Id項目）にアクセスしたときは関連Entityがロードされず、キー項目以外にアクセスしたときのみロードされるようになりました。

キー項目にアクセスすることで関連Entityのロードを行っている場合に、この変更の影響を受ける可能性があります。 キー項目にアクセスしてもロードが行われないため、意図しないポイントで関連Entityのロードが行われることになります。 EntityManagerの生存期間外で関連Entityのロードが行われた場合、org.hibernate.LazyInitializationExceptionが発生しますので、ご注意ください。

[手順が必要なケース]

以下の条件をすべて満たす場合

• データベースアクセスにJPAを利用している
• 関連EntityのLazy Loadを利用している
• キー項目（@Id項目）にアクセスすることで関連Entityのロードを行っている

なお、関連エンティティのLazy Loadを利用しているかどうかの判断は開発ガイドラインの IDを指定してEntityを1件取得 のNote「関連Entityのロードタイミングについて」をご参照ください。

また、キー項目（@Id項目）にアクセスすることで関連Entityのロードを行っている実装例を以下に記載します。

以下の例では、Serviceクラスから主Entity（Reserve）を通して、関連Entity（Customer）のcustomerCodeにアクセスしています。

主Entity

@Entity
@Table(name = "reserve")
public class Reserve implements Serializable {

    // omitted getter and setter
    @JoinColumn(name = "customer_code", referencedColumnName = "customer_code")
    @ManyToOne(optional = false, fetch = FetchType.LAZY)
    private Customer customer;
}

関連Entity

@Entity
@Table(name = "customer")
public class Customer implements Serializable {

    // omitted getter and setter
    @Id
    @Column(name = "customer_code")
    private String customerCode;

    @Column(name = "customer_name")
    private String customerName;
}

Service

// キー項目にアクセスしている例
reserve.getCustomer().getCustomerCode();

[修正方法]

関連Entityのロードを行っている箇所では、キー項目以外にアクセスするように修正します。 例えば上記例では、customerCodeではなくcustomerNameにアクセスするよう修正します。

[備考]

なお、併せてLazy Loadを行う関連Entityの引き継ぎについて、 開発ガイドラインの OpenEntityManagerInViewInterceptorの設定 にて 新たにWarning「意図せぬLazyInitializationExceptionの発生を防止するために」が追加されました。

Lazy Loadを行う関連Entityの引き継ぎの注意点追加に伴う対応を参照して必要な対応を行ってください。

Hibernate 5.0では、PostgreSQLでnowaitを使用するよう設定しても、発行するSQLにnowait句が付加されない場合がありました(HHH-10797)。

この不具合がHibernate 5.2.1で修正され発生しなくなりました。

[手順が必要なケース]

Hibernate 5.2.0以前とPostgreSQLを合わせて使用し、 nowait 句が付加されない不具合の対応を行っていた場合、必要に応じて修正を行ってください。

[修正内容]

不具合の対応を削除してください。

Hibernate 5.2.11において、不完全なQuery(JPQL)が実行されてしまうバグが修正されました。

Hibernate 5.2.10以前においては、Query(JPQL)に余分な閉じ括弧があった場合、それ以降が無視された不完全なQuery(JPQL)が実行されてしまうバグが存在しましたが、 Hibernate 5.2.11で修正され、Query(JPQL)解釈時に例外がスローされるように改善されました。

開発ガイドラインで紹介している方法では、

• Queryメソッドで@Queryアノテーションのvalue属性に指定したJPQL
• カスタムメソッドでEntityManager#createQueryに指定したJPQL

で発生することを確認しています。

詳細は、HibernateのJIRA( HHH-11942 )をご参照ください。

[手順が必要なケース]

余分な閉じ括弧を含む不正なQuery(JPQL)を記載していた場合。

上記に当てはまる場合、バージョンアップに伴ってQuery(JPQL)解釈時にIllegalArgumentExceptionが発生します。

[修正方法]

Query(JPQL)から余分な閉じ括弧を削除してください。

併せて、移行前のバージョンでは不完全なQuery(JPQL)が実行されてしまっていたため、アプリケーションの挙動に問題がなかったか、影響調査を実施してください。

従来、Hibernate Validatorの独自アノテーションであった@Email、@NotBlank、@NotEmptyは、Bean Validation 2.0より標準で提供されるようになりました。 これに伴い、Hibernate Validator 6.0より、Hibernate Validatorが提供する@Email、@NotBlank、@NotEmptyは非推奨となりました。 引き続き使用することは出来ますが、Bean Validationで提供されるアノテーションを使用することを推奨します。

[手順が必要なケース]

Hibernate Validatorが提供する以下のいずれかのアノテーションを使用している場合は、次の修正を行うことを推奨します。

• org.hibernate.validator.constraints.Email
• org.hibernate.validator.constraints.NotBlank
• org.hibernate.validator.constraints.NotEmpty

[修正方法]

Bean Validationで提供される標準のアノテーションに変更します。

具体的には、アノテーションを利用しているJavaクラスのimport文（FormクラスやEntityクラス等）、及びメッセージ定義ファイルを修正します。

以下にそれぞれの修正例を記載します。 （Javaクラスの例では、Formクラスで利用している場合の例を記載しますが、その他のクラスで利用している場合も同様になります。）

• Formクラス

【修正前】

import org.hibernate.validator.constraints.Email;
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.NotEmpty;

public class UserForm implements Serializable {

    @Email
    private String userMailAddress;

    @NotBlank
    private String userName;

    @NotEmpty
    private String userAddrese;

    // ommited getter and setter
}

【修正後】

import javax.validation.constraints.Email;
import javax.validation.constraints.NotBlank;
import javax.validation.constraints.NotEmpty;

public class UserForm implements Serializable {

    @Email
    private String userMailAddress;

    @NotBlank
    private String userName;

    @NotEmpty
    private String userAddrese;

    // ommited getter and setter
}

• メッセージ定義ファイル

ValidationMessages.propertiesを利用している場合、アノテーションのFQCNを修正してください。

【修正前】

## omitted
org.hibernate.validator.constraints.Email.message       = not a well-formed email address
org.hibernate.validator.constraints.NotBlank.message    = may not be empty
org.hibernate.validator.constraints.NotEmpty.message    = may not be empty

【修正後】

## omitted
javax.validation.constraints.Email.message              = not a well-formed email address
javax.validation.constraints.NotBlank.message           = may not be empty
javax.validation.constraints.NotEmpty.message           = may not be empty

5.4.1以前でサポートしていたBean Validation 1.1(Hibernate Validator 5.x)では、コレクション内の値に対して入力チェックを行うためには、 5.4.1の開発ガイドラインの コレクション内の値をBean Validationのアノテーションを使用してチェックする方法 のように、 独自アノテーションやラッパークラスを作成する必要がありました。

5.5.1でサポートするBean Validation 2.0(Hibernate Validator 6.x)より、Bean Validation 2.0の標準仕様として、List<@NotNull String>のように、コレクション内の各値に対してBean ValidationやHibernate Validatorのアノテーションを付与し、チェックすることが可能になりました。

共通ライブラリで提供されるアノテーションも、同様にコレクション内の各値に付与してチェックすることが可能になりました。

[手順が必要なケース]

この手順の適用は任意ですが、以下のケースに当てはまる場合は、次の修正を行うことを推奨します。

• 5.4.1の開発ガイドラインの Java SE 8とHibernate Validator 5.2+による実装 に基づく入力チェックを行っている場合
• 5.4.1の開発ガイドラインの Java Beanを使ったStringのラッパークラスによる実装 に基づく入力チェックを行っている場合

[修正方法：Java SE 8とHibernate Validator 5.2+による実装に基づく入力チェックを行っている場合]

5.4.1の開発ガイドラインの Java SE 8とHibernate Validator 5.2+による実装 で紹介しているような「TYPE_USE」を使用し、型指定部分に付加できるアノテーションを削除し、Bean Validation 2.0に準拠したアノテーションを利用します。 以下では、5.4.1の開発ガイドラインで紹介している、共通ライブラリが提供している@ExistInCodeListをラップし、型指定部分に付加できる@ExistInCodeListForTypeArgumentを実装している場合の修正例を記載します。

【修正前】

利用箇所

import javax.validation.Valid;

import com.example.common.validation.ExistInCodeListForTypeArgument;

public class SampleForm {

    @Valid
    private List<@ExistInCodeListForTypeArgument(codeListId = "CL_ROLE") String> roles;
    // ommited

}

【修正後】

• @ExistInCodeListForTypeArgumentを削除します。

利用箇所

• List内の要素値に対する入力チェックを有効にするために付与していた、javax.validation.Validアノテーションを削除します。
• 型指定部分には、@ExistInCodeListForTypeArgumentの代わりに@ExistInCodeListを付与します。

import org.terasoluna.gfw.common.codelist.ExistInCodeList;

public class SampleForm {

    private List<@ExistInCodeList(codeListId = "CL_ROLE") String> roles;
    // ommited

}

本ガイドで紹介している以外のアノテーションであっても、@TargetにTYPE_USEが指定されているアノテーションについては、本ガイドの修正後と同様に実装することが可能となります。

[修正方法：Java Beanを使ったStringのラッパークラスによる実装に基づく入力チェックを行っている場合]

5.4.1の開発ガイドラインの Java Beanを使ったStringのラッパークラスによる実装 で紹介しているネストしたBean及びFormatterを削除し、 5.5.1の開発ガイドラインの コレクション内の値のチェック のように実装し直してください。

5.4.1以前でサポートしていたBean Validation 1.1(Hibernate Validator 5.x)では、一つのフィールドに同じアノテーションを複数するためには、 5.4.1の開発ガイドラインの バリデーションのグループ化 のコード例のように、Listで囲う必要がありました。

5.5.1でサポートするBean Validation 2.0(Hibernate Validator 6.x)より、Bean Validation 2.0の標準仕様として、Listで囲うことなく複数指定できるようになりました。

共通ライブラリで提供されるアノテーションも、同様にListで囲うことなく複数指定することが可能になりました。

[手順が必要なケース]

この手順の適用は任意ですが、以下のケースに当てはまる場合は、次の修正を行うことを推奨します。

• 5.4.1の開発ガイドラインの バリデーションのグループ化 のコード例のように、一つのフィールドに同じアノテーションを複数するためにListで囲んでいる場合

[修正方法]

5.4.1の開発ガイドラインの バリデーションのグループ化 で紹介しているUserFormクラスの修正例を記載します。

【修正前】

public class UserForm implements Serializable {

    @NotNull
    @Min.List({
            @Min(value = 18, groups = Chinese.class),
            @Min(value = 20, groups = Japanese.class),
            @Min(value = 21, groups = Singaporean.class)
            })
    @Max(200)
    private Integer age;

    // ommited

}

【修正後】

public class UserForm implements Serializable {

    @NotNull
    @Min(value = 18, groups = Chinese.class)
    @Min(value = 20, groups = Japanese.class)
    @Min(value = 21, groups = Singaporean.class)
    @Max(200)
    private Integer age;

    // ommited

}

本ガイドで紹介している以外のアノテーションであっても、アノテーションにRepeatableが付与されたアノテーションについては、本ガイドの修正後と同様に実装することが可能となります。

サポートするDozerのバージョンが5.5.1から6.4.1にバージョンアップしました。

バージョンアップに伴い、ソースコード全体に影響する以下の変更が加わりました。

• ライブラリ名称に関わる変更

  • DozerのアーティファクトIDの変更
  • DozerおよびDozer SpringのグループIDの変更

• Dozerを利用するソースコードに関わる変更

  • DozerおよびDozer Springのベースパッケージ名の変更
  • マッピング定義XMLファイルのXMLスキーマを取得するURLの変更

上記のうち、ライブラリ名称に関わる変更は共通ライブラリで対応されており、利用する側での対応は不要です。 Dozerを利用するソースコードに関わる変更に対する対応を行っていただく必要があります。

なお、より理解を深めるためには、DozerのGitHubで公開されているマイグレーションページを合わせて参照してください。

Dozer 5.5.1からDozer 6.4.1の間で、Dozer及びDozer Springのベースパッケージ名が com.github.dozermapperに変更され、Dozerのパッケージ名にはコアライブラリであることを明示するcoreが付与されました。

結果、以下のように整理されました。

• Dozer

org.dozer　⇒　com.github.dozermapper.core

• Dozer Spring

org.dozer.spring　⇒　com.github.dozermapper.spring

[手順が必要なケース]

この手順の適用は必須です。

[修正方法]

Bean定義ファイル

DozerBeanMapperFactoryBeanのパッケージ名を変更します。 ブランクプロジェクトであれば、applicationContext.xmlを以下のように修正します。

【修正前】

<bean id="beanMapper" class="org.dozer.spring.DozerBeanMapperFactoryBean"> <!-- ### 修正箇所 ### -->
    <property name="mappingFiles"
        value="classpath*:/META-INF/dozer/**/*-mapping.xml" />
</bean>

【修正後】

<bean id="beanMapper" class="com.github.dozermapper.spring.DozerBeanMapperFactoryBean"> <!-- ### 修正箇所 ### -->
    <property name="mappingFiles"
        value="classpath*:/META-INF/dozer/**/*-mapping.xml" />
</bean>

Javaファイル（Controllerなど）

以下のように、変更後のパッケージ名のクラスを利用するように修正してください。 例として、Mapperを利用している場合を記載します。

【修正前】

import org.dozer.Mapper;

【修正後】

import com.github.dozermapper.core.Mapper;

上記はMapperを利用している場合の例になりますが、 例えばDozerConverterを拡張したカスタムコンバーターを作成している場合などでは、Mapperを利用している箇所以外も 同様にパッケージ名を修正する対応が必要になります。

Dozer 6.1.0から、マッピング定義XMLファイルのXMLスキーマURLが変更されました。

[手順が必要なケース]

マッピング定義XMLファイル(src/main/resources/META-INF/dozer/(任意の値)-mapping.xml)を作成している場合、この手順の適用は必須です。

[修正方法]

DozerのXMLスキーマURLを以下のように修正してください。

【修正前】

<?xml version="1.0" encoding="UTF-8"?>
<!-- ### 修正箇所 ここから ### -->
<mappings xmlns="http://dozer.sourceforge.net"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://dozer.sourceforge.net http://dozer.sourceforge.net/schema/beanmapping.xsd">
<!-- ### 修正箇所 ここまで ### -->
<!-- omitted -->

【修正後】

<?xml version="1.0" encoding="UTF-8"?>
<!-- ### 修正箇所 ここから ### -->
<mappings xmlns="http://dozermapper.github.io/schema/bean-mapping"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://dozermapper.github.io/schema/bean-mapping https://dozermapper.github.io/schema/bean-mapping.xsd">
<!-- ### 修正箇所 ここまで ### -->
<!-- omitted -->

Dozer 6.3.0から、マッピング定義XMLファイルの解析にJAXBが使われるようになりました。

これにより、既存のマッピング定義XMLファイルの一部の記述がJAXBでは正常に処理されず、不具合が発生する可能性があります。

例として、Dozer 6.2.0以前では無視されていたマッピング定義XMLファイルのコンテンツ（タグ内の値）の前後に存在する改行コードが、 Dozer 6.3.0以降では値として読み取られるようになった事象を確認しています。

この事象を回避する方法を以下に示します。

[修正方法]

タグ内の不要な改行を削除します。

【修正前】

<copy-by-reference>
    org.terasoluna.tourreservation.domain.model.*
</copy-by-reference>

【修正後】

<copy-by-reference>org.terasoluna.tourreservation.domain.model.*</copy-by-reference>

[備考]

Java 11を利用する場合、JAXBを利用するための設定が必要となります。開発ガイドラインの JAXBの削除 を合わせて参照してください。

Dozer 6.1.0以前では、同名フィールドは<mapping>タグのtype属性にone-wayを付与しても正常に単方向マッピングとならず、逆方向でもマッピングされるバグが存在します。 TERASOLUNA Server Framework for Java 5.4.X以前はDozer 6.1.0以前のバージョンを使用しているため、バグの影響を受けていました。

具体的には、<mapping>タグのtype属性にone-wayを付与した場合、フィールドが別名であれば正常に単方向マッピングとなりますが、それ以外の項目は双方向マッピングされていました。

詳細は、開発ガイドラインの 単方向・双方向マッピング の Note「Dozer 6.1.0以前のバージョンに存在する単方向マッピングのバグについて」を参照してください。

[手順が必要なケース]

以下の条件をすべて満たす場合、本バグ修正の影響がないことを確認してください。

• 単方向マッピングを利用している
• 同名フィールドをマッピングしている

上記に当てはまる場合、本来実現したい動作が以下のどちらに当てはまるかを確認してください。

• 全てのフィールドを単方向マッピングにしたい
• 異名フィールドのみ単方向マッピングにしたい（Dozer 6.1.0以前と同様の動作を実現したい）

前者の場合、修正は不要です。 後者の場合、以下のように修正してください。

[修正方法]

<mapping>タグのtype属性からone-wayを削除し、 単方向マッピングにしたいフィールドの<field>タグのtype属性にone-wayを付与してください。

【修正前】

<mapping type="one-way">
    <class-a>xxx.Source</class-a>
    <class-b>xxx.Destination</class-b>
    <field>
        <a>SourceName</a>
        <b>DestinationName</b>
    </field>
</mapping>

【修正後】

<mapping>
    <class-a>xxx.Source</class-a>
    <class-b>xxx.Destination</class-b>
    <field type="one-way">
        <a>SourceName</a>
        <b>DestinationName</b>
    </field>
</mapping>

Dozer 6.4.0から、JSR-310 Date and Time APIが提供する以下のクラスのマッピングがサポートされました。

• java.time.LocalDate
• java.time.LocalTime
• java.time.LocalDateTime
• java.time.OffsetTime
• java.time.OffsetDateTime
• java.time.ZonedDateTime

上記のクラスをマッピングするために独自にカスタムコンバーターを作成していた場合、カスタムコンバーターが不要となります。

なお、上記6クラス以外をマッピングする場合は、従来通りカスタムコンバーターを作成する必要があります。

[手順が必要なケース]

この手順の適用は任意ですが、以下のケースに当てはまる場合は、次の修正を行うことを推奨します。

• 上記のクラスをマッピングするために独自にカスタムコンバーターを作成していた場合

[修正方法]

開発ガイドラインの カスタムコンバーターの作成 で作成した カスタムコンバーター、及び作成したカスタムコンバーターをマッピングに利用するための定義を削除してください。

削除後は、Dozer標準のマッピングで従来のカスタムコンバーターの仕様を代替できることを、テスト等実施してご確認ください。

[備考]

JSR-310の日付・時刻オブジェクトから文字列への変換において、マッピング定義XMLファイルの<date-format>で指定したフォーマットの妥当性チェックに、本来はjava.time.format.DateTimeFormatterが使用されるはずが java.text.SimpleDateFormatが使用されているため、 JSR-310で使用できるはずのパターン文字が使用できない不具合 が確認されています。

詳細は、開発ガイドラインの 文字列から日付・時刻オブジェクトへのマッピング のWarningを参照してください。

5.4.1以前の開発ガイドラインでは Collectionマッピング のTodoにおいて、 Collection<T>を使用したマッピングは失敗する旨が記載されていました。

実際には、Dozer 5.5.1でCollection<T>を使用したマッピングに対応されたため、TERASOLUNA Server Framework for Java 5.0.0以降を利用している場合、マッピングが可能です。

[手順が必要なケース]

この手順の適用は任意ですが、以下のケースに当てはまる場合は、次の修正を行うことを推奨します。

• Collection<T>をDozerを利用せず手動でコピーしている場合

[修正方法]

Dozerを利用してマッピングを行うように修正します。

修正後は、Dozer標準のマッピングでCollection<T>のマッピングができることを、テスト等実施してご確認ください。

この更新手順は、release site からダウンロードしたEclipse WTPプロジェクト向けです。

Note

凡例

[テーブルヘッダ]

Non : O/R Mapperに非依存のブランクプロジェクト

MB3 : MyBatis3用のブランクプロジェクト

JPA : JPA用のブランクプロジェクト

[備考欄]

* : オペレーション対象

Eclipse WTP Project of 5.5.1.RELEASE をダウンロードしてください。

Eclipseが起動している場合、Eclipseを終了します。

$YOUR_ECLIPSE_WTP_PROJECT/src/main/webapp/WEB-INF/lib のjarファイルを更新(削除して追加)してください。

.. tabularcolumns:: |p{0.25\linewidth}|p{0.30\linewidth}|p{0.30\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|

$YOUR_ECLIPSE_WTP_PROJECT/testlib のjarファイルを更新(削除して追加)してください。

.. tabularcolumns:: |p{0.25\linewidth}|p{0.30\linewidth}|p{0.30\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|

$YOUR_ECLIPSE_WTP_PROJECT/libsrc のソース格納用jarファイルを更新(削除して追加)してください。

.. tabularcolumns:: |p{0.25\linewidth}|p{0.30\linewidth}|p{0.30\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|

置換文字列を使用して、参照ライブラリを更新してください。

• $YOUR_ECLIPSE_WTP_PROJECT/.classpath
• $YOUR_ECLIPSE_WTP_PROJECT/build.xml

.. tabularcolumns:: |p{0.25\linewidth}|p{0.30\linewidth}|p{0.30\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|

Eclipse WTPプロジェクトの設定から参照ライブラリ(以下のjarファイル)を削除してください。

• $YOUR_ECLIPSE_WTP_PROJECT/.classpath
• $YOUR_ECLIPSE_WTP_PROJECT/build.xml

.. tabularcolumns:: |p{0.30\linewidth}|p{0.55\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|

[修正方法]

.classpath

<!-- ### 以下のクラスパスエントリーの削除が必要 ### -->

<!-- omitted -->

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/aopalliance-1.0.jar"
    sourcepath="libsrc/aopalliance-1.0-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/dozer-5.5.1.jar"
    sourcepath="libsrc/dozer-5.5.1-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/dozer-spring-5.5.1.jar"
    sourcepath="libsrc/dozer-spring-5.5.1-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/geronimo-jta_1.1_spec-1.1.1.jar"
    sourcepath="libsrc/geronimo-jta_1.1_spec-1.1.1-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar"
    sourcepath="libsrc/hibernate-jpa-2.1-api-1.0.0.Final-sources.jar" />

<classpathentry kind="lib"
    path="testlib/cglib-nodep-2.1_3.jar"
    sourcepath="libsrc/cglib-nodep-2.1_3-sources.jar" />

<classpathentry kind="lib"
    path="testlib/cssparser-0.9.18.jar"
    sourcepath="libsrc/cssparser-0.9.18-sources.jar" />

<classpathentry kind="lib"
    path="testlib/gson-2.8.1.jar"
    sourcepath="libsrc/gson-2.8.1-sources.jar" />

<classpathentry kind="lib"
    path="testlib/httpmime-4.5.3.jar"
    sourcepath="libsrc/httpmime-4.5.3-sources.jar" />

<classpathentry kind="lib"
    path="testlib/htmlunit-2.21.jar"
    sourcepath="libsrc/htmlunit-2.21-sources.jar" />

<classpathentry kind="lib"
    path="testlib/htmlunit-core-js-2.17.jar"
    sourcepath="libsrc/htmlunit-core-js-2.17-sources.jar" />

<classpathentry kind="lib"
    path="testlib/htmlunit-driver-2.21.jar"
    sourcepath="libsrc/htmlunit-driver-2.21-sources.jar" />

<classpathentry kind="lib"
    path="testlib/jetty-client-9.4.6.v20170531.jar"
    sourcepath="libsrc/jetty-client-9.4.6.v20170531-sources.jar" />

<classpathentry kind="lib"
    path="testlib/jetty-http-9.4.6.v20170531.jar"
    sourcepath="libsrc/jetty-http-9.4.6.v20170531-sources.jar" />

<classpathentry kind="lib"
    path="testlib/jetty-io-9.4.6.v20170531.jar"
    sourcepath="libsrc/jetty-io-9.4.6.v20170531-sources.jar" />

<classpathentry kind="lib"
    path="testlib/jetty-util-9.4.6.v20170531.jar"
    sourcepath="libsrc/jetty-util-9.4.6.v20170531-sources.jar" />

<classpathentry kind="lib"
    path="testlib/jna-4.2.2.jar"
    sourcepath="libsrc/jna-4.2.2-sources.jar" />

<classpathentry kind="lib"
    path="testlib/jna-platform-4.1.0.jar"
    sourcepath="libsrc/jna-platform-4.1.0-sources.jar" />

<classpathentry kind="lib"
    path="testlib/neko-htmlunit-2.21.jar"
    sourcepath="libsrc/neko-htmlunit-2.21-sources.jar" />

<classpathentry kind="lib"
    path="testlib/netty-3.5.7.Final.jar"
    sourcepath="libsrc/netty-3.5.7.Final-sources.jar" />

<classpathentry kind="lib"
    path="testlib/sac-1.3.jar"
    sourcepath="libsrc/sac-1.3-sources.jar" />

<classpathentry kind="lib"
    path="testlib/selenium-leg-rc-2.53.1.jar"
    sourcepath="libsrc/selenium-leg-rc-2.53.1-sources.jar" />

<classpathentry kind="lib"
    path="testlib/serializer-2.7.2.jar"
    sourcepath="libsrc/serializer-2.7.2-sources.jar" />

<classpathentry kind="lib"
    path="testlib/websocket-api-9.4.6.v20170531.jar"
    sourcepath="libsrc/websocket-api-9.4.6.v20170531-sources.jar" />

<classpathentry kind="lib"
    path="testlib/websocket-client-9.4.6.v20170531.jar"
    sourcepath="libsrc/websocket-client-9.4.6.v20170531-sources.jar" />

<classpathentry kind="lib"
    path="testlib/websocket-common-9.4.6.v20170531.jar"
    sourcepath="libsrc/websocket-common-9.4.6.v20170531-sources.jar" />

<classpathentry kind="lib"
    path="testlib/xalan-2.7.2.jar"
    sourcepath="libsrc/xalan-2.7.2-sources.jar" />

<classpathentry kind="lib"
    path="testlib/xercesImpl-2.11.0.jar"
    sourcepath="libsrc/xercesImpl-2.11.0-sources.jar" />

<classpathentry kind="lib"
    path="testlib/xml-apis-1.4.01.jar"
    sourcepath="libsrc/xml-apis-1.4.01-sources.jar" />

<!-- omitted -->

build.xml

<!-- ### 以下のクラスパスエントリーの削除が必要 ### -->

<path id="build.classpath">
    <!-- omitted -->
    <pathelement location="${lib.dir}/aopalliance-1.0.jar"/>
    <pathelement location="${lib.dir}/dozer-5.5.1.jar"/>
    <pathelement location="${lib.dir}/dozer-spring-5.5.1.jar"/>
    <pathelement location="${lib.dir}/geronimo-jta_1.1_spec-1.1.1.jar"/>
    <pathelement location="${lib.dir}/hibernate-jpa-2.1-api-1.0.0.Final.jar"/>
    <!-- omitted -->
</path>

<path id="build.test.classpath">
    <!-- omitted -->
    <pathelement location="${testlib.dir}/cglib-nodep-2.1_3.jar"/>
    <pathelement location="${testlib.dir}/cssparser-0.9.18.jar"/>
    <pathelement location="${testlib.dir}/gson-2.8.1.jar"/>
    <pathelement location="${testlib.dir}/httpmime-4.5.3.jar"/>
    <pathelement location="${testlib.dir}/htmlunit-2.21.jar"/>
    <pathelement location="${testlib.dir}/htmlunit-core-js-2.17.jar"/>
    <pathelement location="${testlib.dir}/htmlunit-driver-2.21.jar"/>
    <pathelement location="${testlib.dir}/jetty-client-9.4.6.v20170531.jar"/>
    <pathelement location="${testlib.dir}/jetty-http-9.4.6.v20170531.jar"/>
    <pathelement location="${testlib.dir}/jetty-io-9.4.6.v20170531.jar"/>
    <pathelement location="${testlib.dir}/jetty-util-9.4.6.v20170531.jar"/>
    <pathelement location="${testlib.dir}/jna-4.2.2.jar"/>
    <pathelement location="${testlib.dir}/jna-platform-4.1.0.jar"/>
    <pathelement location="${testlib.dir}/neko-htmlunit-2.21.jar"/>
    <pathelement location="${testlib.dir}/netty-3.5.7.Final.jar"/>
    <pathelement location="${testlib.dir}/sac-1.3.jar"/>
    <pathelement location="${testlib.dir}/selenium-leg-rc-2.53.1.jar"/>
    <pathelement location="${testlib.dir}/serializer-2.7.2.jar"/>
    <pathelement location="${testlib.dir}/websocket-api-9.4.6.v20170531.jar"/>
    <pathelement location="${testlib.dir}/websocket-client-9.4.6.v20170531.jar"/>
    <pathelement location="${testlib.dir}/websocket-common-9.4.6.v20170531.jar"/>
    <pathelement location="${testlib.dir}/xalan-2.7.2.jar"/>
    <pathelement location="${testlib.dir}/xercesImpl-2.11.0.jar"/>
    <pathelement location="${testlib.dir}/xml-apis-1.4.01.jar"/>
    <!-- omitted -->
</path>

Eclipse WTPプロジェクトの設定に参照ライブラリ(jarファイル以下)を追加してください。

• $YOUR_ECLIPSE_WTP_PROJECT/.classpath
• $YOUR_ECLIPSE_WTP_PROJECT/build.xml

.. tabularcolumns:: |p{0.30\linewidth}|p{0.55\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|

[修正方法]

.classpath

<!-- ### 以下のクラスパスエントリーの追加が必要 ### -->

<!-- omitted -->
<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/animal-sniffer-annotations-1.17.jar"
    sourcepath="libsrc/animal-sniffer-annotations-1.17-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/byte-buddy-1.9.7.jar"
    sourcepath="libsrc/byte-buddy-1.9.7-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/checker-qual-2.5.2.jar"
    sourcepath="libsrc/checker-qual-2.5.2-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/dozer-core-6.4.1.jar"
    sourcepath="libsrc/dozer-core-6.4.1-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/dozer-spring4-6.4.1.jar"
    sourcepath="libsrc/dozer-spring4-6.4.1-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/error_prone_annotations-2.2.0.jar"
    sourcepath="libsrc/error_prone_annotations-2.2.0-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/failureaccess-1.0.1.jar"
    sourcepath="libsrc/failureaccess-1.0.1-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/j2objc-annotations-1.1.jar"
    sourcepath="libsrc/j2objc-annotations-1.1-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/javax.activation-api-1.2.0.jar"
    sourcepath="libsrc/javax.activation-api-1.2.0-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/javax.persistence-api-2.2.jar"
    sourcepath="libsrc/javax.persistence-api-2.2-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/jaxb-api-2.3.1.jar"
    sourcepath="libsrc/jaxb-api-2.3.1-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/jboss-transaction-api_1.2_spec-1.1.1.Final.jar"
    sourcepath="libsrc/jboss-transaction-api_1.2_spec-1.1.1.Final-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/jsr305-3.0.2.jar"
    sourcepath="libsrc/jsr305-3.0.2-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar"
    sourcepath="libsrc/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava-sources.jar" />

<classpathentry kind="lib"
    path="src/main/webapp/WEB-INF/lib/spring-jcl-5.1.4.RELEASE.jar"
    sourcepath="libsrc/spring-jcl-5.1.4.RELEASE-sources.jar" />

<classpathentry kind="lib"
    path="testlib/byte-buddy-agent-1.9.7.jar"
    sourcepath="libsrc/byte-buddy-agent-1.9.7-sources.jar" />

<classpathentry kind="lib"
    path="testlib/okhttp-3.10.0.jar"
    sourcepath="libsrc/okhttp-3.10.0-sources.jar" />

<classpathentry kind="lib"
    path="testlib/okio-1.14.1.jar"
    sourcepath="libsrc/okio-1.14.1-sources.jar" />

<classpathentry kind="lib"
    path="testlib/selenium-java-3.14.0.jar"
    sourcepath="libsrc/selenium-java-3.14.0-sources.jar" />

<classpathentry kind="lib"
    path="testlib/selenium-opera-driver-3.14.0.jar"
    sourcepath="libsrc/selenium-opera-driver-3.14.0-sources.jar" />

<!-- omitted -->