1概要

Spring Bootは、Springエコシステムへの根拠のあるアプローチをもたらします。

2014年半ばに最初にリリースされました。 Spring Bootは多くの開発と改良を経てきました。そのバージョン2.0は今日2018年の初めにリリースの準備ができています。

この人気のある図書館が私たちを助けようとしているさまざまな分野があります。

  • 依存関係管理初心者から様々なパッケージマネージャまで

統合
** 自動設定Springの設定量を最小限にしようとする

アプリは行く準備を整え、大会を支持する必要があります
構成
** プロダクション対応機能

Actuator

など、より良いロギング

モニタリング、測定基準、またはさまざまなPAAS統合
** 開発経験を強化しました。複数のテストユーティリティまたは


spring-boot-devtools

を使ったより良いフィードバックループ

この記事では、Spring Boot 2.0で予定されているいくつかの変更点と機能について説明します。また、これらの変更が私たちの生産性向上にどのように役立つかについても説明します。


2依存関係


2.1. Javaベースライン

  • Spring Boot 2.xはJava 7以下をサポートしなくなり、Java 8が最小要件になります。

Java 9をサポートする最初のバージョンでもあります。1.xブランチでJava 9をサポートする予定はありません。つまり、最新のJavaリリースを使用してこのフレームワークを利用したい場合は、Spring Boot 2.xが唯一の選択肢です** 。


2.2. 部品表

Spring Bootの新しいリリースごとに、Javaエコシステムのさまざまな依存関係のバージョンがアップグレードされます。これはブートリンクで定義されています。

2.xではこれも例外ではありません。それらをリストしても意味がありませんが、https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-dependencies/pom.xmlを見てください。[

spring-boot-dependencies.pom

]は、どの時点でどのバージョンが使用されているのかを確認します。

最低限必要なバージョンに関するいくつかのハイライト:

  • Tomcatの最小サポートバージョンは8.5です

  • Hibernateの最小サポートバージョンは5.2です。

  • Gradleの最小サポートバージョンは3.4です


2.3. Gradleプラグイン

Gradleプラグインは大幅な改良といくつかの大きな変更を経てきました。

太いjarファイルを作成するために、

bootRepackage

Gradleのタスクは

bootJar



bootWar

** に置き換えられ、それぞれjarファイルとwarsファイルが作成されます。

Gradleプラグインを使用してアプリを1.xで実行したい場合は、

gradle bootRunを実行できます。私たちは通常、古典的な

JavaExec__タスクで使用します。

時々、私たちは自分自身がSpring Boot BOMを利用したいと思うことがあります。しかし、完全なBootアプリを作成したり、それを再パッケージ化したくない場合があります。

この点に関して、Spring Boot 2.xがデフォルトで依存関係管理プラグインを適用しなくなることを知っておくと面白いです。

Spring Bootの依存関係管理が必要な場合は、以下を追加する必要があります。

apply plugin: 'io.spring.dependency-management'

これにより、上記のシナリオではより少ない構成でより高い柔軟性が得られます。


3自動設定


3.1. セキュリティ

2.xでは、セキュリティ設定は劇的に単純化されました。 ** デフォルトでは、静的リソースやアクチュエータのエンドポイントを含むすべてのものが保護されています。

ユーザーが明示的にセキュリティを設定すると、Spring Bootのデフォルトは影響を受けなくなります。その後、ユーザーはすべてのアクセスルールを1か所で設定できます。

これにより、WebSecurityConfigureAdapterの順序付けの問題に取り組むことができなくなります。通常、これらの問題は、アクチュエータとアプリケーションのセキュリティルールを独自の方法で設定するときに発生します。

アクチュエータとアプリケーションのルールを組み合わせた簡単なセキュリティスニペットを見てみましょう。

http.authorizeRequests()
  .requestMatchers(EndpointRequest.to("health"))
    .permitAll()//Actuator rules per endpoint
  .requestMatchers(EndpointRequest.toAnyEndpoint())
    .hasRole("admin")//Actuator general rules
  .requestMatchers(PathRequest.toStaticResources().atCommonLocations())
    .permitAll()//Static resource security
  .antMatchers("/** ** ")
    .hasRole("user")//Application security rules
 //...


3.2. リアクティブサポート

  • Spring Boot 2は、さまざまなリアクティブモジュール用に新しいスターターのセットをもたらします。いくつかの例は、WebFlux、およびMongoDB、Cassandra、またはRedisの対応する対応物です。

WebFlux用のテストユーティリティもあります。特に、@@ WebFluxTestを利用することができます。これは、元々1.4.0でさまざまなテスト

slices

の一部として導入された古い

@ WebMvcTest

と同じように動作します。


4生産対応機能

Spring Bootは、私たちがプロダクション対応アプリケーションを作成できるようにするための便利なツールをいくつかもたらします。とりわけ、私たちはSpring Boot Actuatorを利用することができます。

Actuatorには、監視、トレース、および一般的なアプリのイントロスペクションを簡素化するためのさまざまなツールが含まれています。アクチュエーターについてのさらなる詳細は私達のリンクで見つけることができます:/spring-boot-actuators[前の記事]。

  • 2バージョンの

    actuator

    では、大幅な改善が行われています。** この反復では、カスタマイズの簡略化に焦点が当てられています。また、新しいリアクティブモジュールを含む他のWeb技術もサポートしています。


4.1. 技術サポート

  • Spring Boot 1.xでは、アクチュエータのエンドポイントとしてSpring-MVCのみがサポートされていました。しかし、2.xでは、独立してプラグイン可能になりました。** Springブートは、WebFlux、Jersey、およびSpring-MVCのサポートをすぐに利用できるようになりました。

以前と同様に、JMXは選択肢のままであり、構成によって有効または無効にすることができます。


4.2. カスタムエンドポイントの作成

  • 新しいアクチュエータインフラストラクチャはテクノロジに依存しません。このため、開発モデルは最初から再設計されました。

新しいモデルはまたより大きい柔軟性および表現力をもたらします。

アクチュエータ用の

Fruits

エンドポイントを作成する方法を見てみましょう。

@Endpoint(id = "fruits")
public class FruitsEndpoint {

    @ReadOperation
    public Map<String, Fruit> fruits() { ... }

    @WriteOperation
    public void addFruits(@Selector String name, Fruit fruit) { ... }
}


ApplicationContextに

FruitsEndpoint__を登録すると、選択したテクノロジを使用してWebエンドポイントとして公開できます。構成によっては、JMX経由で公開することもできます。

エンドポイントをWebエンドポイントに変換すると、次のようになります。

  • /application/fruits



    GET__が果物を返す


  • POST


    /applications/fruits/\ {a-fruit}

    その果物の取り扱い

ペイロードに含める必要があります

もっとたくさんの可能性があります。より細かいデータを取得できます。

また、基盤となるテクノロジごとに特定の実装を定義することもできます(JMXとWebなど)。この記事の目的のために、私達はそれをあまり詳細に入らないで簡単な紹介として保つつもりです。


4.3. アクチュエータのセキュリティ

Spring Boot 1.x Actuatorでは、独自のセキュリティモデルを定義しています。このセキュリティモデルは、我々のアプリケーションで使用されているものとは異なります。

これは、ユーザーがセキュリティを向上させようとしたときの多くの問題点の根本でした。

2.xでは、セキュリティ設定は他のアプリケーションが使用するのと同じ設定を使用して設定する必要があります。

デフォルトでは、ほとんどのアクチュエータエンドポイントは無効になっています。これは、Spring Securityがクラスパスにあるかどうかとは無関係です。

status

と__infoを超えて、他のすべてのエンドポイントはユーザーによって有効にされる必要があります。

** 4.4. その他の重要な変更点

  • ほとんどの設定プロパティは現在

    management.xxx

    の下にあります。


management.endpoints.jmx

** いくつかのエンドポイントは新しいフォーマットを持ちます。例:

env、flyway

、または

liquibase

  • 定義済みのエンドポイントパスは設定できなくなりました


5強化された開発経験


5.1. より良いフィードバック

Spring bootは1.3で

devtools

を導入しました。

それは典型的な開発問題を平らにするのを引き受けます。たとえば、ビューテクノロジのキャッシュなどです。自動再起動とブラウザのライブリロードも実行します。また、アプリをリモートデバッグすることもできます。

  • 2.xでは、アプリケーションが

    devtools

    によって再起動されると、「デルタ」レポートが印刷されます** 。このレポートでは、何が変更されたのか、またそれがアプリケーションに与える影響について説明します。

Spring Bootによって設定されたものをオーバーライドするJDBCデータソースを定義するとしましょう。

D

__evtools


は自動設定されたものがもう作成されていないことを示します。また、原因を指摘します。タイプ

javax.sql.DataSource.



@ ConditionalOnMissingBean__の不一致は、再起動後にこのレポートを印刷します。

** 5.2. 大きな変更点

JDK 9の問題により、devtoolsはHTTPによるリモートデバッグのサポートを終了しています。


6. 概要

この記事では、Spring Boot 2がもたらす変更のいくつかを取り上げました。

依存関係と、Java 8がサポートされる最小バージョンになる方法について説明しました。

次に、自動設定について話しました。私たちはとりわけセキュリティに注目しました。私達はまたアクチュエーターおよびそれが受け取った多くの改善について話した。

最後に、提供された開発ツールで行われたいくつかのマイナーな調整について話しました。