さて、前回の投稿でお知らせした通り、今回から数回に渡って、Springフレームワークで開発されたアプリケーションをQuarkusでラップして、ネイティブビルドおよび実行ができるようにするまでの手順をご紹介したいと思います。
全体のコアとなる「application-core」と上の図で示した部分は、Springフレームワークをベースとしたアプリケーションとして成立しており、それをQuarkusによってRESTやgRPCによって公開するだけという状態を想定してください。今回のサンプルプロジェクトは「Mujo」と同じようにgRPCサービスとして公開しています。
ところで、私の肌感では、Jakarta EE(CDI)よりも、Springフレームワークを開発に利用するプロジェクトの方が多く、知見も十分に浸透している印象です。
既存の資産をフル活用しながら、ネイティブアプリケーションとして小さなメモリフットプリントで素早く起動できると、各種クラウドのコンテナサービスとの親和性も高く、アプリケーションのリリースサイクルを大きく改善することができるのではないかと考えています。
さて、前置きが長くなりましたが、ここからは適宜コードも参照しながら、読み進めていただければと思います。
こちらが今回サンプルで利用するアプリケーションのコアとなるSpringフレームワークベースのライブラリプロジェクト（以下、コアライブラリ）です。
機能としては、システム設定によって指定されたパスで、ファイルの読み書きを行うとてもシンプルなものです。テキストファイル、バイナリファイルをそれぞれ別のパスで管理できるようにしています。
続いてこちらは、QuakrusベースのアプリケーションでgRPCサーバーとして起動し、コアライブラリで提供している機能をそのままラップしています。
どちらのプロジェクトもstep1からstep7までのブランチがあります。
それぞれのブランチは、ひとつ前のブランチをベースブランチにしています。
ブランチ同士の比較をもって、各ステップではどのような変更をしたのかが分かるようになっています。（それぞれのプロジェクトのREADMEにも、どのような変更をしたかは記載しています）
それぞれのステップ（ブランチ）で、ネイティブアプリケーションとして起動できるようにするまでにどのような工程を辿ったのか、以下の表に簡単にまとめましたので、ご参照ください。
| 工程 | 主な変更点 | BootApplication OK? | ネイティブビルド OK? |
|---|---|---|---|
| step1 | Quarkusのspring diエクステンションを用いて、コアライブラリを利用（コアライブラリはSpringExtensionによるUTが通っている状態） | × | × |
| step2 | CDIの流儀に則り、コアライブラリに空のbeans.xmlを追加 | × | × |
| step3 | コアライブラリのあいまいなBean定義を修正 | × | × |
| step4 | EnvironmentをQuakrusから注入 | 〇 | × |
| step5 | コアライブラリにEnvironmentの代替コンポーネントを追加 | 〇 | 〇 |
| step6 | Quakrusのapplication.propertiesにログ出力の設定を追加 | 〇 | 〇 |
| step7 | コアライブラリのBeanライフサイクルメソッドを明示的に呼び出すように変更 | 〇 | 〇 |
上の表の「BootApplication」というのは、Quakrusアプリケーションのエントリーポイントでメインメソッドを持つクラスです。このクラスをIDEなどから実行した場合は、QuarkusのJVMモードで起動されます。
step5からはDockerでビルドしたネイティブアプリケーションをコンテナ内で起動して動作確認ができるようになります。
少々長くなりましたので、今回はここまでとして、次回からはコードの変更点に具体的にフォーカスしていきたいと思います。
それでは！