menu
書いてる野郎
orebike@gmail.com
Seasar2 とかのプロジェクトでは Hotdeploy とか呼ばれていた機能。Live Reload とか言っている場合もある。
Java は IDE ばっかり使っていると勘違いしてしまうが、書かれているソースコードのファイルがそのまま解釈されて動くわけでなく、一度実行形式にコンパイルされた上で動いている。 なので実際に動いているモノと目の前で書いているモノは別物のためサーバサイドのプログラムのように実行が2段階になっているもの、つまり、サーバを起動して、それに対するリクエストによって実行がトリガーされるモノは Eclipse からの実行トリガーだけでは動作せず、Eclipse で起動、そしてリクエストで実行という動きになる。
ここで開発の段階に目を向けると、修正して → リロード → リクエスト → 確認 という動きをやることになり面倒になる。 しかも、このリロードはサーバ全体になるため時間がかかることが多い。
ここで、修正 → リクエスト → 確認 とできるように、修正した瞬間に自動リロードして開発効率をあげるのが「自動リロード」
プロジェクトの build.gradle に
dependencies { compile('org.springframework.boot:spring-boot-starter-thymeleaf') compile('org.springframework.boot:spring-boot-starter-web') compile("org.springframework.boot:spring-boot-devtools") testCompile('org.springframework.boot:spring-boot-starter-test') }
このように spring-boot-devtools を追記する。
そしてプロジェクト全体をリフレッシュすると、ダウンロードが始まるのだ。
起動の仕方は普通と変わらない。 STS ではプロジェクトを右クリックして Run As → Spring Boot App を選ぶと、ズラズラ出てきて起動する。
この状態で元のソースコードを変更するとアプリ側が勝手にリロードして変更が反映される
STS なしで エディタと Gradle でやる場合は
このように gradle を起動して、ファイルの変更待ち状態にしておく
$ ./gradlew build --continuous
これによって、ソースに変更があると都度ビルドされる。 つまり Gradle が起動しっぱなしになっている。
この状態で起動すれば変更の度に再起動する必要もなく反映される。
$ ./gradlew bootRun
デフォルトの設定では再起動の度にセッションが切れてしまうので、ログインを前提とするモノを作っている時は都合が悪い。 そこで application.yml にこのように書いておくと再起動してもセッションを維持してくれる。
server: session: persistent: true