かんがるーさんの日記

最近自分が興味をもったものを調べた時の手順等を書いています。今は Spring Boot をいじっています。

Spring Boot 2.0.x の Web アプリを 2.1.x へバージョンアップする ( その２ )( Gradle を 4.10.3 → 5.2 にバージョンアップする )

概要

記事一覧はこちらです。

Spring Boot 2.0.x の Web アプリを 2.1.x へバージョンアップする ( その１ )( 概要 ) の続きです。

  • 今回の手順で確認できるのは以下の内容です。
    • Gradle の 5 系がリリースされていますので、Gradle を 4.10.3 → 5.2 にバージョンアップします。

参照したサイト・書籍

目次

  1. 2.1.x ブランチの作成
  2. Gradle を 4.10.3 → 5.0 へバージョンアップする。。。が compileTestJava で lombok が適用されない
  3. Gradle を 5.0 → 5.2 へバージョンアップするも状況変わらず
  4. build.gradle に testAnnotationProcessor の定義を追加する
  5. lombok の設定で annotationProcessor, testAnnotationProcessor や compileOnly, testCompileOnly を併記しなくてもよいように build.gradle を変更する
  6. gradlew.bat の DEFAULT_JVM_OPTS の設定を変更する
  7. Gradle 5 の BOM import 機能に切り替えて io.spring.dependency-management plugin を削除しよう。。。と思ったが止める

手順

2.1.x ブランチの作成

master から 2.1.x ブランチを、2.1.x から feature/133-issue ブランチを作成します。

Gradle を 4.10.3 → 5.0 へバージョンアップする。。。が compileTestJava で lombok が適用されない

まずは Upgrading your build from Gradle 4.x to 5.0 に従い Gradle を 5.0 へバージョンアップします。

gradle help --scan コマンドを実行します。Publishing a build scan to scans.gradle.com requires accepting the Gradle Terms of Service defined at https://gradle.com/terms-of-service. Do you accept these terms? [yes, no] のメッセージが表示されたら yes を入力します。

f:id:ksby:20190206103840p:plain

Publishing build scan... のメッセージの下に URL が表示されますので、その URL にアクセスしてメールアドレスを入力します。

メールアドレスに「Your build scan for 'ksbysample-webapp-lending' from ...」という件名のメールが届きますので、その中の「Discover your build」ボタンをクリックして「Build Scan」画面を表示します。何か対応が必要な場合には画面左側の「Console log」の下に「Deprecations」が表示されるとのことですが、表示されませんでしたので次に進みます。

f:id:ksby:20190206104323p:plain

build.gradle の wrapper タスクの記述を以下のように変更します。

wrapper {
    gradleVersion = "5.0"
    distributionType = Wrapper.DistributionType.ALL
}
  • gradleVersion = "4.10.3" → gradleVersion = "5.0" に変更します。

コマンドプロンプトから gradlew wrapper --gradle-version 5.0、gradlew --version コマンドを実行します。

f:id:ksby:20190206110555p:plain

gradle/wrapper/gradle-wrapper.properties は以下の内容になります。

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-5.0-all.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新した後、clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると test のコンパイルが失敗して "BUILD FAILED" のメッセージが出力されました。

f:id:ksby:20190206112421p:plain f:id:ksby:20190206112523p:plain

コンパイルが失敗したのは src/test/java/ksbysample/test/ItemTypeStringToCodeConversion.java の下の赤枠の箇所ですが、どうも lombok の @Getter アノテーションが適用されていないようです。

f:id:ksby:20190206115551p:plain

原因がよく分からないので、一旦 gradle を 5.2 まで上げてみます。

Gradle を 5.0 → 5.2 へバージョンアップするも状況変わらず

build.gradle の wrapper タスクの記述を以下のように変更します。

wrapper {
    gradleVersion = "5.2"
    distributionType = Wrapper.DistributionType.ALL
}
  • gradleVersion = "5.0" → gradleVersion = "5.2" に変更します。

コマンドプロンプトから gradlew wrapper --gradle-version 5.2、gradlew --version コマンドを実行します。

f:id:ksby:20190206130302p:plain

Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新した後、clean タスク実行 → Rebuild Project 実行 → build タスクを実行して見ましたが状況が変わりませんでした。。。

build.gradle に testAnnotationProcessor の定義を追加する

Upgrading your build from Gradle 4.x to 5.0、Upgrading your build from Gradle 5.x には解決しそうな記述は見当たらず Web で調べてもよく分からなかったのですが、build.gradle を見ていてふと気づいたことがありました。

今は build.gradle の dependencies block に lombok の設定を以下のように記述しているのですが、

    // for lombok
    annotationProcessor("org.projectlombok:lombok:${lombokVersion}")
    compileOnly("org.projectlombok:lombok:${lombokVersion}")
    testCompileOnly("org.projectlombok:lombok:${lombokVersion}")

compileOnly に testCompileOnly があるように、まさか annotationProcessor にも testAnnotationProcessor があるのかな。。。と思って入力してみたところ、ありました！　ということは testAnnotationProcessor の記述がないので compileTestjava タスクで lombok のアノテーションプロセッサが実行されていなかったのでしょう。

f:id:ksby:20190206155912p:plain

build.gradle に testAnnotationProcessor("org.projectlombok:lombok:${lombokVersion}") を追加してから、

    // for lombok
    annotationProcessor("org.projectlombok:lombok:${lombokVersion}")
    testAnnotationProcessor("org.projectlombok:lombok:${lombokVersion}")
    compileOnly("org.projectlombok:lombok:${lombokVersion}")
    testCompileOnly("org.projectlombok:lombok:${lombokVersion}")

Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新した後、clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると無事 "BUILD SUCCESSFUL" のメッセージが出力されました。

f:id:ksby:20190206161506p:plain

lombok の設定で annotationProcessor, testAnnotationProcessor や compileOnly, testCompileOnly を併記しなくてもよいように build.gradle を変更する

もう少し調べてみたところ compileOnly dependencies are not available in tests を見つけました。build.gradle の configurations block に testImplementation.extendsFrom compileOnly を記述しておくと compileOnly と testCompileOnly を併記しなくても良くなるようです。

build.gradle を以下のように変更します。

configurations {
    // annotationProcessor と testAnnotationProcessor、compileOnly と testCompileOnly を併記不要にする
    testAnnotationProcessor.extendsFrom annotationProcessor
    testImplementation.extendsFrom compileOnly

    // for Doma 2
    domaGenRuntime
}

..........

dependencies {
    ..........

    // for lombok
    // testAnnotationProcessor、testCompileOnly を併記しなくてよいよう configurations で設定している
    annotationProcessor("org.projectlombok:lombok:${lombokVersion}")
    compileOnly("org.projectlombok:lombok:${lombokVersion}")
  • configurations block に以下の２行を追加します。
    • testImplementation.extendsFrom compileOnly
    • testAnnotationProcessor.extendsFrom annotationProcessor
  • dependencies block の lombok の設定から以下の２行を削除します。
    • testAnnotationProcessor("org.projectlombok:lombok:${lombokVersion}")
    • testCompileOnly("org.projectlombok:lombok:${lombokVersion}")

Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新した後、clean タスク実行 → Rebuild Project 実行 → build タスクを実行すると "BUILD SUCCESSFUL" のメッセージが出力されました。

f:id:ksby:20190206164254p:plain

gradlew.bat の DEFAULT_JVM_OPTS の設定を変更する

Gradle をバージョンアップした際に変更されたファイルを確認したところ、gradlew.bat 内の DEFAULT_JVM_OPTS が以前は何も設定されていなかったのが -Xmx64m が設定されるようになっていました。

f:id:ksby:20190206212927p:plain

さすがに -Xmx64m は小さいので set DEFAULT_JVM_OPTS="-Xmx64m" → set DEFAULT_JVM_OPTS="-Xmx4096m" に変更します。

Gradle 5 の BOM import 機能に切り替えて io.spring.dependency-management plugin を削除しよう。。。と思ったが止める

Gradle 5 から io.spring.dependency-management plugin を使用しなくても BOM を直接参照できるようになりました。BOM import に記述があります。Gradle 5 の機能に切り替えてみます。

build.gradle を以下のように変更します。

plugins {
    id "java"
    id "eclipse"
    id "idea"
    id "org.springframework.boot" version "2.0.8.RELEASE"
    id "groovy"
    id "checkstyle"
    id "com.github.spotbugs" version "1.6.8"
    id "pmd"
    id "net.ltgt.errorprone" version "0.0.16"
    id "de.undercouch.download" version "3.4.3"
    id "com.gorylenko.gradle-git-properties" version "2.0.0-beta1"
}

..........

dependencies {
    def jdbcDriver = "org.postgresql:postgresql:42.2.5"
    def spockVersion = "1.2-groovy-2.5"
    def domaVersion = "2.21.0"
    def lombokVersion = "1.18.4"
    def errorproneVersion = "2.3.1"
    def powermockVersion = "2.0.0"
    def spotbugsVersion = "3.1.10"

    // BOM
    // https://repo.spring.io/release/org/springframework/boot/spring-boot-dependencies/2.0.8.RELEASE/spring-boot-dependencies-2.0.8.RELEASE.pom
    implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)

    // BOM によりバージョン番号が自動で設定されるもの
    // Appendix F. Dependency versions ( https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-dependency-versions.html ) 参照
    implementation("org.springframework.boot:spring-boot-starter-web")
    ..........

    // BOM によりバージョン番号が自動で設定されないもの、あるいは最新バージョンを指定したいもの
    ..........
    testImplementation("cglib:cglib-nodep:3.2.10")
    testImplementation("org.codehaus.groovy:groovy-all:2.5.4")
    testImplementation("org.spockframework:spock-core:${spockVersion}")
    ..........
  • plugins block から id "io.spring.dependency-management" version "1.0.6.RELEASE" を削除します。
  • dependencies block の上に記述していた dependencyManagement block を削除します。
  • dependencies block の以下の点を変更します。
    • implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES) を追加します。
    • implementation platform(...) の方法では bomProperty "groovy.version", "2.5.4" や ext["groovy.version"] = "2.5.4" を記述することで BOM 内の property の値を変更することができないので、 testImplementation("org.codehaus.groovy:groovy-all:2.5.4") を追加して groovy 及び関連ライブラリのバージョンを 2.5.4 にします。

Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新します。io.spring.dependency-management plugin の時と gradlew dependencies コマンドの実行結果を比較してみたところ、主に以下の点が異なっていました。

  • 以前は org.slf4j:slf4j-api のバージョンが 1.8.0-beta2 -> 1.7.25 にダウングレードされていたのですが、今度は 1.8.0-beta2 になっていました。
  • compileClasspath、default、runtimeClasspath 等に org.springframework.boot:spring-boot-dependencies:2.0.8.RELEASE と依存しているライブラリが追加されていました。
  • implementation に org.springframework.boot:spring-boot-dependencies:2.0.8.RELEASE が追加されていました（依存しているライブラリはなし）。
  • org.apache.tomcat.embed:tomcat-embed-core:8.5.37 の依存関係に org.apache.tomcat:tomcat-annotations-api:8.5.37 が表示されるようになりました。
  • org.thymeleaf:thymeleaf:3.0.11.RELEASE の依存関係に以下の２つのライブラリが表示されるようになりました。
    • ognl:ognl:3.1.12
    • org.javassist:javassist:3.20.0-GA -> 3.22.0-GA
  • compileOnly に org.springframework.boot:spring-boot-configuration-processor が表示されるのですが、以前は org.springframework.boot:spring-boot-configuration-processor -> 2.0.8.RELEASE と表示されていたのですが org.springframework.boot:spring-boot-configuration-processor FAILED と表示されるようになりました。

thymeleaf の依存関係に ognl が出てくるのと org.springframework.boot:spring-boot-configuration-processor のバージョンが解決出来ず FAILED になるのが気になります。今回は io.spring.dependency-management plugin を使う方式に戻します。

履歴

2019/02/07
初版発行。

Spring Boot 2.0.x の Web アプリを 2.1.x へバージョンアップする ( その１ )( 概要 )

概要

記事一覧はこちらです。

  • 「Spring Boot で書籍の貸出状況確認・貸出申請する Web アプリケーションを作る」で作成した Web アプリケーション ( ksbysample-webapp-lending ) の Spring Boot のバージョンを 2.0.8 → 2.1.x へバージョンアップします。
  • 進め方は以下の方針とします。
    • Git のブランチは 2.1.x を作成して、そちらで作業します。Spring Boot のバージョンと合わせます。
    • 最初に Gradle のバージョンを 4.10.3 → 5.x へバージョンアップします。
    • 次に Spring Boot のバージョン番号を 2.1.x にします。
      • Spring Initializr で 2.1.x のプロジェクトを作成して、修正した方がよさそうな点があれば反映します。
      • ライブラリは最新バージョンにアップデートします。
    • プロジェクトを build し直してエラーが出る点があれば修正し、まずはここまでで動くようにします。
    • その後で 2.1 系ではこう書くべきという点があるか確認し、変更した方がよいところを修正します。
    • 最後に Java SE を Oracle の 8 から AdoptOpenJDK の 11 に変更します。

　
2.1 の Release Notes はこちらです。

Spring Boot 2.1 Release Notes
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.1-Release-Notes

履歴

2019/02/06
初版発行。

Spring Boot 2.0.x の Web アプリを 2.1.x へバージョンアップする ( 大目次 )

  1. その１ ( 概要 )
  2. その２ ( Gradle を 4.10.3 → 5.2 にバージョンアップする )
  3. その３ ( build.gradle を変更する )
  4. その４ ( テストが大量に失敗する原因を解消する )
  5. その５ ( テストが大量に失敗する原因を解消する２ )
  6. 番外編 ( IntelliJ IDEA の Class Diagram 生成機能メモ書き )
  7. 番外編 ( Spring Initializr で作成したプロジェクトで Thymeleaf テンプレートのコード補完を有効にするには？ )
  8. その６ ( Thymeleaf テンプレートの html タグの属性を変更し、メトリックスのタグの定義場所を変更する )
  9. その７ ( Gradle を 5.2 → 5.2.1 へ、Spring Boot を 2.1.2 → 2.1.3 へバージョンアップする )
  10. その８ ( JUnit 5 へバージョンアップ。。。したいが @RunWith(Enclosed) ＋ @Unroll ＋ useJUnitPlatform() を組み合わせるとテストが終わらない )
  11. その９ ( JUnit 5 へバージョンアップ。。。@RunWith(Enclosed) ＋ @Unroll ＋ useJUnitPlatform() の組み合わせでテストが終わらない問題を解決する )
  12. その１０ ( @Rule を使用していないテストを JUnit 5 のテストに書き直す＋JUnit 5 の Parallel 実行を試してみる )
  13. その１１ ( @Rule を使用しているテストを JUnit 5 のテストに書き直す )
  14. その１２ ( @Rule を使用しているテストを JUnit 5 のテストに書き直す２ )
  15. その１３ ( @WebMvcTest、@WithAnonymousUser、@WithMockUser を使ってみる )
  16. その１４ ( Docker で複数の Tomcat を起動して動作確認する )
  17. その１５ ( JDK を 8u202 → 11.0.2+9 に変更する )
  18. その１６ ( JDK を 8u202 → 11.0.2+9 に変更する２ )
  19. その１７ ( JDK 11 環境下で error-prone を復活させる )
  20. 番外編 ( テストクラス内の @Component を付与したクラスを Bean として登録するには？ )
  21. その１８ ( Gradle を 5.2.1 → 5.3.1 へ、Spock を 1.2 → 1.3 へ、JUnit 5 を 5.4.0 → 5.4.1 へバージョンアップする )
  22. その１９ ( dependency-management plugin を 1.0.6 → 1.0.7 へ、Checkstyle を 8.17 → 8.19 へ、PMD を 6.11.0 → 6.13.0 へバージョンアップする )
  23. その２０ ( Spring Boot を 2.1.3 → 2.1.4 へバージョンアップする )
  24. 感想

Java SE を 8u192 → 8u202 へ、IntelliJ IDEA を 2018.3.3 → 2018.3.4 へバージョンアップ

Java SE を 8u192 → 8u202 へバージョンアップする

※ksbysample-webapp-lending プロジェクトを開いた状態でバージョンアップしています。

  1. Oracle の Java SE Downloads を見ると 8u202 がダウンロードできるようになっていましたので、8u202 へバージョンアップします。

  2. jdk-8u202-windows-x64.exe をダウンロードして D:\Java\jdk1.8.0_202 へインストールした後、環境変数 JAVA_HOME のパスを D:\Java\jdk1.8.0_202 へ変更します。

    コマンドプロンプトから java -version を実行し、1.8.0_202 に変更されていることを確認します。

    f:id:ksby:20190202093707p:plain

  3. IntelliJ IDEA を再起動した後、プロジェクトで使用する Java SE を 8u202 へ変更します。

  4. 開いているプロジェクトを閉じて「Welcome to IntelliJ IDEA」ダイアログを表示します。

  5. ダイアログ下部の「Configure」-「Project Defaults」-「Project Structure」を選択します。

    f:id:ksby:20190202094452p:plain

  6. 「Default Project Structure」ダイアログが表示されます。画面左側で「Project Settings」-「Project」を選択後、画面右側の「Project SDK」の「New...」ボタンをクリックし、表示されるメニューから「JDK」を選択します。

    f:id:ksby:20190202094729p:plain

  7. 「Select Home Directory for JDK」ダイアログが表示されます。D:\Java\jdk1.8.0_202 を選択した後、「OK」ボタンをクリックします。

    f:id:ksby:20190202094853p:plain

  8. 「Default Project Structure」ダイアログに戻るので、今度は「Project SDK」の「Edit」ボタンをクリックします。

    f:id:ksby:20190202095040p:plain

  9. 画面左側で「Platform Settings」-「SDKs」が選択された状態になるので、画面右上の入力フィールドで "1.8" → "1.8.0_202" へ変更します。

    f:id:ksby:20190202095257p:plain

  10. 次に中央のリストから「1.8.0_192」を選択した後、リストの上の「－」ボタンをクリックして削除します。

    f:id:ksby:20190202095444p:plain

  11. 「OK」ボタンをクリックして「Default Project Structure」ダイアログを閉じます。

  12. 「Welcome to IntelliJ IDEA」ダイアログに戻ったら、ksbysample-webapp-lending プロジェクトを開きます。

  13. IntelliJ IDEA のメイン画面が開いたら、メニューから「File」-「Project Structure...」を選択します。

  14. 「Project Structure」ダイアログが表示されます。以下の画像の状態になっているので、

    f:id:ksby:20190202095747p:plain

    ※今回から「Project language level」に選択されている設定が「1.3 - Plain old Java」ではなく「SDK default」に変わっていました。

    「Project SDK」を選択し直します。「Project language level」は「Project SDK」を「1.8.0_202」に変更したら「SDK default (8 - Lambdas, type annotations etc.)」が表示されました。

    f:id:ksby:20190202095928p:plain

  15. 「OK」ボタンをクリックして「Project Structure」ダイアログを閉じます。

  16. メイン画面に戻ると画面右下に「Indexing...」の表示が出るので、終了するまで待ちます。

    f:id:ksby:20190202100442p:plain

  17. clean タスク実行 → Rebuild Project 実行 → build タスクを実行して、"BUILD SUCCESSFUL" のメッセージが出力されることを確認します。

    f:id:ksby:20190202101335p:plain

  18. Project Tool Window で src/test を選択した後、コンテキストメニューを表示して「Run ‘All Tests’ with Coverage」を選択し、テストが全て成功することを確認します。

    f:id:ksby:20190202101946p:plain

  19. 特に問題は発生しませんでした。8u202 で開発を進めます。

IntelliJ IDEA を 2018.3.3 → 2018.3.4 へバージョンアップする

IntelliJ IDEA の 2018.3.4 がリリースされているのでバージョンアップします。

※ksbysample-webapp-lending プロジェクトを開いた状態でバージョンアップしています。

  1. IntelliJ IDEA のメインメニューから「Help」-「Check for Updates...」を選択します。

  2. 「IDE and Plugin Updates」ダイアログが表示されます。左下に「Update and Restart」ボタンが表示されていますので、「Update and Restart」ボタンをクリックします。

    f:id:ksby:20190202104651p:plain

  3. Plugin の update も表示されました。このまま「Update and Restart」ボタンをクリックします。

    f:id:ksby:20190202104730p:plain

  4. Patch がダウンロードされて IntelliJ IDEA が再起動します。

  5. IntelliJ IDEA が起動すると画面下部に「Indexing…」のメッセージが表示されますので、終了するまで待機します。

    f:id:ksby:20190202105142p:plain

  6. IntelliJ IDEA のメインメニューから「Help」-「About」を選択し、2018.3.4 へバージョンアップされていることを確認します。

  7. Gradle Tool Window の左上にある「Refresh all Gradle projects」ボタンをクリックして更新します。

  8. clean タスク実行 → Rebuild Project 実行 → build タスクを実行して、"BUILD SUCCESSFUL" のメッセージが出力されることを確認します。

    f:id:ksby:20190202105842p:plain

  9. Project Tool Window で src/test を選択した後、コンテキストメニューを表示して「Run 'All Tests' with Coverage」を選択し、テストが全て成功することを確認します。

    f:id:ksby:20190202110427p:plain

Spring Boot 1.5.x の Web アプリを 2.0.x へバージョンアップする ( 感想 )

記事一覧はこちらです。

  • さすがにメジャーバージョンアップだけあって変更点が多かったです。Spring Boot 2.0 Migration Guide が用意されているので、読みながら対応すればそれ程困らないでしょう。バージョンアップに伴う修正ボリュームはそれなりにありますが、難しいイメージはないですね。

  • Spring Actuator を入れて Prometheus+Grafana と連携してメトリックスを表示するのが気に入りました！　簡単にメトリックスを表示できるようになるのは便利ですね。個人的には Reactive 対応よりも嬉しい機能かもしれません。

  • PC を Windows 10 に変えたので、今回は開発環境一式を Docker で起動するようにしてみました。Spring Boot 2 のバージョンアップよりも Docker 対応していた期間の方が長かったです。Docker でサーバを起動する環境を構築できましたが、反省点もいろいろありました。

    • 市販されている書籍を何冊か読んではいたのですが、実際やってみると結構苦労しますね。Redis Cluster はすごく面倒でした。。。　RabbitMQ なんてほぼコピペですしね。「無理にクラスタ構成にする必要はないんじゃないかな」と何度思ったことか。。。
    • 単一インスタンスのサーバを構築するよりマルチインスタンス／クラスタ構成のサーバを構築した方がいろいろ調べることになってスキルアップする気がします。
    • 有名なソフトの Official イメージの Dockerfile は目を通した方がいいですね。自分で Dockerfile を書く時も Official イメージの Dockerfile を参考にしました。

次は 2.1.x へのバージョンアップをやる予定です。Gradle も 5.x へバージョンアップし、Java も AdoptOpenJDK の 11 へ切り替えます。

Spring Boot 1.5.x の Web アプリを 2.0.x へバージョンアップする ( その３６ )( Windows のサービスから起動して動作確認する )

概要

記事一覧はこちらです。

Spring Boot 1.5.x の Web アプリを 2.0.x へバージョンアップする ( その３５ )( Docker で起動しているサーバの TimeZone を Asia/Tokyo に変更する ) の続きです。

  • 今回の手順で確認できるのは以下の内容です。

参照したサイト・書籍

目次

  1. jar ファイルを作成、配置する
  2. サービスに登録する
  3. 動作確認
  4. サービスから削除する
  5. 次回は。。。

手順

jar ファイルを作成、配置する

docker-compose up -d でコンテナを起動した後、clean タスク実行 → Rebuild Project 実行 → build タスク実行します。

C:\project-springboot\ksbysample-webapp-lending\build\libs の下に ksbysample-webapp-lending-2.0.8-RELEASE.jar が作成されますので、C:\webapps\ksbysample-webapp-lending\lib の下に配置します。

webapps/ksbysample-webapp-lending/bat/webapp_startup.bat を以下の内容に変更した後、C:\webapps\ksbysample-webapp-lending\bat の下にコピーします。

@echo on

setlocal
set JAVA_HOME=D:\Java\jdk1.8.0_192
set PATH=%JAVA_HOME%\bin;%PATH%
set WEBAPP_HOME=D:\webapps\ksbysample-webapp-lending
set WEBAPP_JAR=ksbysample-webapp-lending-2.0.8-RELEASE.jar
set LOGS_DIR=%WEBAPP_HOME%\logs
set PATH_HEAPDUMPFILE=%LOGS_DIR%\heapdump.hprof
set PATH_ERRORFILE=%LOGS_DIR%\hs_err.log

cd /d %WEBAPP_HOME%
java -server ^
     -Xms1024m -Xmx1024m ^
     -XX:MaxMetaspaceSize=384m ^
     -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled ^
     -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 ^
     -XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark ^
     -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps ^
     -Xloggc:%WEBAPP_HOME%/logs/gc.log ^
     -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M ^
     -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=%PATH_HEAPDUMPFILE% ^
     -XX:+CrashOnOutOfMemoryError ^
     -XX:ErrorFile=%PATH_ERRORFILE% ^
     -Dsun.net.inetaddr.ttl=100 ^
     -Dcom.sun.management.jmxremote ^
     -Dcom.sun.management.jmxremote.port=7900 ^
     -Dcom.sun.management.jmxremote.ssl=false ^
     -Dcom.sun.management.jmxremote.authenticate=false ^
     -Dspring.profiles.active=product ^
     -jar lib\%WEBAPP_JAR%

set YYYYMMDD=%date:~0,4%%date:~5,2%%date:~8,2%
set HHMMSS=%time:~0,8%
set HHMMSS=%HHMMSS::=%
set HHMMSS=%HHMMSS: =%
if exist %PATH_HEAPDUMPFILE% rename %PATH_HEAPDUMPFILE% heapdump_%YYYYMMDD%%HHMMSS%.hprof
if exist %PATH_ERRORFILE% rename %PATH_ERRORFILE% hs_err_%YYYYMMDD%%HHMMSS%.log

サービスに登録する

コマンドプロンプトを「管理者として実行...」モードで起動した後、以下のコマンドを実行します。

> cd /d D:\webapps\ksbysample-webapp-lending\nssm
> nssm.exe install ksbysample-webapp-lending

「NSSM service installer」画面が表示されます。以下の画像の値を入力した後、「Install service」ボタンをクリックします。サービスの登録に成功すると「Service "ksbysample-webapp-lending" installed successfully!」のダイアログが表示されますので「OK」ボタンをクリックします。

f:id:ksby:20190123211425p:plain

  • 「Path」に D:\webapps\ksbysample-webapp-lending\bat\webapp_startup.bat を入力します。
  • 「Startup directory」に D:\webapps\ksbysample-webapp-lending\bat を入力します。

動作確認

  1. 動作確認前に DB のデータを以下の状態にします。

    • user_info, user_role テーブルのデータは開発時のままにします。
    • lending_app, lending_book, library_forsearch テーブルのデータはクリアします。

  2. サービス画面を開きます。サービス一覧から「ksbysample-webapp-lending」を選択し、「サービスの開始」リンクをクリックしてサービスを開始します。

    f:id:ksby:20190123212446p:plain f:id:ksby:20190123212527p:plain

  3. D:\webapps\ksbysample-webapp-lending\logs の下の ksbysample-webapp-lending.log をエディタで開き、最後に "Started Application in ..." のログが出力されていることを確認します。

  4. 以下の手順で動作確認します ( 画面キャプチャは省略します )。

    • ブラウザを起動して http://localhost:8080/ にアクセスしてログイン画面を表示します。tanaka.taro@sample.com / taro でログインします。
    • 検索対象図書館登録画面が表示されます。"東京都" で検索した後、一覧表示されている図書館から「国立国会図書館東京本館」を選択します。
    • ログアウトします。
    • ログイン画面に戻るので suzuki.hanako@test.co.jp / hanako でログインします。
    • 貸出希望書籍 CSV ファイルアップロード画面が表示されます。以下の内容が記述された CSV ファイルをアップロードします。

      "ISBN","書名"
      "978-4-7741-6366-6","GitHub実践入門"
      "978-4-7741-5377-3","JUnit実践入門"
      "978-4-7973-8014-9","Java最強リファレンス"
      "978-4-7973-4778-4","アジャイルソフトウェア開発の奥義"
      "978-4-87311-704-1","Javaによる関数型プログラミング"

    • 「貸出状況を確認しました」のメールが送信されるので、メールに記述されている URL にアクセスします。
    • 貸出申請画面が表示されます。３冊程「申請する」を選択して申請します。
    • ログアウトします。
    • 「貸出申請がありました」のメールが送信されるので、メールに記述されている URL にアクセスします。ログイン画面が表示されるので、tanaka.taro@sample.com / taro でログインします。
    • 貸出承認画面が表示されます。「承認」あるいは「却下」を選択して確定させます。
    • ログアウトします。
    • 「貸出申請が承認・却下されました」のメールが送信されるので、メールに記述されている URL にアクセスします。ログイン画面が表示されるので、suzuki.hanako@test.co.jp / hanako でログインします。
    • 貸出申請結果確認画面が表示されるので内容を確認します。

    動作確認は特に問題ありませんでした。

  5. サービス画面で「ksbysample-webapp-lending」サービスを停止します。

サービスから削除する

サービスを削除します。管理者モードで起動しているコマンドプロンプトから以下のコマンドを実行します。

> nssm.exe remove ksbysample-webapp-lending

「Remove the service?」のダイアログが表示されますので、「はい」ボタンをクリックします。サービスが削除されると「Service "ksbysample-webapp-lending" removed successfully!」のダイアログが表示されますので「OK」ボタンをクリックします。

次回は。。。

感想を書いて完了させる予定です。

履歴

2019/01/24
初版発行。

Spring Boot 1.5.x の Web アプリを 2.0.x へバージョンアップする ( 番外編 )( docker logs メモ書き )

概要

記事一覧はこちらです。

docker logs で出力されるログはソケットかパイプでコンテナの標準出力・標準エラー出力に出力されたものを受け取って表示していると何となく思っていたのですが、docker logs で表示されるログの保存場所とローテート方法 の記事を読むとどうもログファイルに出力していて、それを読み取って表示しているらしいです。興味が湧いたので確認してみます。

参照したサイト・書籍

  1. docker logs で表示されるログの保存場所とローテート方法
    https://qiita.com/tily/items/adb433505da6c7812725

  2. Docker for WindowsのMobyLinuxVMに接続する方法
    https://qiita.com/gentaro/items/cf666259cb6baf2eb8db

  3. Configure logging drivers
    https://docs.docker.com/config/containers/logging/configure/

目次

  1. docker logs コマンドで出力されるログがログファイルに出力されていることを確認する
  2. log-driver に awslogs を指定すればコンテナのログを Amazon CloudWatch Logs に転送できるらしい

手順

docker logs コマンドで出力されるログがログファイルに出力されていることを確認する

pgadmin4 はログインしているとコンテナのログが出力され続けるので、これでログファイルのサイズが増え続けるのか確認してみます。

docker-compose up -d コマンドでコンテナを起動した後、docker inspect --format '{{ .LogPath }}' pgadmin4 でログファイルのパスを確認します。

f:id:ksby:20190122222149p:plain

Hyper-V 上に作成されている MobyLinuxVM に接続してログファイルを確認します。適当なディレクトリに Dockerfile を新規作成し、以下の内容を記述します。

FROM alpine
MAINTAINER You <you@example.com>
RUN apk update && \
    apk add util-linux && \
    rm -rf /var/cache/apk/*
ENTRYPOINT ["nsenter", "--target", "1", "--mount", "--uts", "--ipc", "--net", "--pid"]

build した後、コンテナを起動して MobyLinuxVM に接続します。

> docker build . -t hostenter
> docker run -it --privileged --pid=host hostenter /bin/sh

接続後、docker inspect --format '{{ .LogPath }}' pgadmin4 コマンドで取得したディレクトリへ移動し、ログファイルのサイズが増え続けていることを確認します。

f:id:ksby:20190122223619p:plain

確かにログファイルが作成されていて、サイズが増え続けていました。ログが出力され続けるコンテナを長時間起動したままにする時は、ログファイルの最大サイズを設定した方が良さそうです。

log-driver に awslogs を指定すればコンテナのログを Amazon CloudWatch Logs に転送できるらしい

Configure logging drivers や Amazon CloudWatch Logs logging driver を見た感じでは、Docker 自体にログ転送の機能が用意されていて、log-driver に awslogs を指定して設定するだけで Amazon CloudWatch Logs に転送できるようです。

試してみたいところですが、今回はメモ書きに留めておきます。2.0.x へのバージョンアップの記事はそろそろ終わらせて 2.1.x の記事に移りたいので。

ここまで docker network、docker volume、docker logs を見ましたが、他にもまだ何かあるのでしょうか。。。

履歴

2019/01/22
初版発行。