Spring Boot 1.5の主な変更点

  • 80
    いいね
  • 0
    コメント

今回は、Spring Boot 1.5.RC1の主な変更点を、リリースノートベースで紹介したいと思います。(1.5の正式リリースは今のところ2017/1/25に設定されており、まだまだ変更が入ると思いますが。。。:smirk:

Note:

2017/01/15 「OAuth 2 Resource Filter」を追加。(RC1リリース後にリリースノートが修正されたため)

Upgrading from Spring Boot 1.4

Spring Boot 1.4からSpring 1.5に移行する際に、影響がでる可能性がある主な変更点は以下の通りです。

Deprecations from Spring Boot 1.4

Spring Boot 1.4で非推奨にしたAPIやプロパティキー」は、1.5で削除されます。
ちなみに・・・HornetQとVelocityは完全にサポート外になるので、Spring Boot 1.5にアップデートする計画がある場合は、今のうちに対策を検討しておいた方がよいと思います。

Renamed starters

Spring Boot 1.4で名前が変更になり非推奨扱いになっていたstarterアーティファクト」は、1.5で削除されます。もしこれらのアーティファクトをまだ使っている場合は・・・

  • spring-boot-starter-wsspring-boot-starter-web-services
  • spring-boot-starter-redisspring-boot-starter-data-redis

を使うようにする必要があります。

Spring Session store

Spring Boot 1.4までは、Spring SessionのセッションストアにRedisを使う場合は特別なコンフィギュレーションをしなくても自動でRedisの設定が適用されていましたが、1.5からは明示的にセッションのストアタイプ(store-type)を指定しないとエラーになるようになっています。(正確にいうと・・・Spring Boot 1.4の時はWARNログが出力されていました)

なので・・・store-typeを明示的に指定していない場合は・・・

src/main/resources/application.properties
spring.session.store-type=redis

を追加する必要があります。

Note:

Spring Sessionを使ったことがないという方は・・・・「Spring Boot+Spring SessionでスケーラブルなステートフルWebアプリが簡単につくれるよ〜」を試してみてください :grin:

Actuator security

Spring Boot 1.4までは、Actuatorのsensitiveなエンドポイント(デフォルトだと/health/info 以外)へ認可制御を行う場合はSpring Securityが必要でしたが、1.5からはSpring Boot単体で認可制御できるようになり、デフォルトで認可制御が有効になっています。
こちらについては・・・ @making@github のブログ「Cloud Foundry :hearts: Spring Boot」をみてください!!

Note:

認可制御が有効になっている状態でActuatorのsensitiveなエンドポイントにアクセスする場合は、Spring Boot 1.4まではデフォルトだとADMINロールを持つユーザでアクセスする必要がありましたが、1.5からはACTUATORロールを持つユーザでアクセスする必要があります。
なお、Actuatorのsensitiveなエンドポイントにアクセスできるロールはプロパティファイルで変更することができるので、1.4と同じ動作にしたい場合は、以下のようなプロパティを追加してください。

src/main/resources/application.properties
management.security.roles=ADMIN

InMemoryMetricRepository

Spring Boot 1.4まではInMemoryMetricRepositoryクラスでMultiMetricRepositoryインタフェースを実装してたけど、1.5からはMultiMetricRepositoryインタフェースを実装したInMemoryMultiMetricRepositoryクラスが新設し、InMemoryMetricRepositoryInMemoryMultiMetricRepositoryの中から使うようにしたよ〜ということみたいですね。
で・・・MetricRepositoryMultiMetricRepositoryというインタフェースを介して利用してるはずだから、この変更は利用者が意識する必要ないはずだよね・・・ということっぽい。

spring.jpa.database

Spring Boot 1.4までは、JPAの実装プロバイダ(Hibernate ORMなど)内で扱うデータベースの種類を指定するプロパティ(spring.jpa.database)を指定する必要がありましたが、1.5から省略することができるようになります。省略した場合は、spring.datasource.urlに指定したURLからデータベースの種類を決定する仕組みになっています。

src/main/resources/application.properties
spring.datasource.url=jdbc:postgresql://localhost:5432/spring
#spring.jpa.database=postgresql # ← Spring Boot 1.5からURLから自動検出されるため省略できる!!

@IntegrationComponentScan

Spring Boot 1.5から、Spring Integration提供の@IntegrationComponentScanを付与したクラスが自動コンフィギュレーションされる仕組みになったため、「Spring Bootが推奨するプロジェクト構成」になっていれば、@IntegrationComponentScanの指定を省略することができるようになります。

ApplicationStartedEvent

Spring Boot 1.5から、Spring Bootアプリケーションの起動開始を通知するイベントクラスの名前がApplicationStartedEventからApplicationStartingEventに変更されます。ApplicationStartedEventは非推奨APIになるので、ApplicationStartingEventを使うようにリファクタリングしましょう。

Spring Integration Starter

Spring Boot 1.5から、spring-boot-starter-integrationspring-integration-jmxが含まれなくなります。spring-integration-jmxを使っている場合は、個別に依存アーティファクトに追加する必要があります。

Devtools excluded by default

Spring Boot 1.5から、spring-boot-devtoolsはjarやwarファイルの中にパッケージされなくなります。
spring-boot-devtoolsから提供されているリモート機能を使いたい場合は、Maven又はGradleのSpring Boot pluginのexcludeDevtoolsオプションにfalseを指定すると、spring-boot-devtoolsがjarやwarファイルの中にパッケージできます。

spring-boot-devtoolsをjarやwarに中に含める際のpom.xmlの定義例
<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <excludeDevtools>false</excludeDevtools>
    </configuration>
</plugin>

Gradle 1.x

Spring Boot 1.5から、GradleのSpring Boot pluginはGradle 1.xで動かないため、Gradle 2.9+のGradleを使うようにする必要があります。

Remote CRaSH shell

Spring Boot 1.5から、「Spring BootアプリケーションにSSHでアクセスして内部の状態を確認できる機能」が非推奨扱いになり、Spring Boot 2.0で廃止されるようです。

OAuth 2 Resource Filter

Spring Boot 1.4では、Actuator(の自動コンフィギュレーション)機能とSpring Security OAuth2提供のリソースサーバ用のコンフィギュレーション機能(@EnableResourceServer)を併用すると、Actuator機能のエンドポイント毎の認可定義に関係なく、OAuth 2の認証(アクセストークンの認証)が要求される動きになっていました(gh-5072)。

つまり・・・デフォルトの動きだとsensitiveでないActuatorのエンドポイント(デフォルトだと/health/info)に認証なしでアクセスできなかった・・・・

$ curl -s -D - http://localhost:8080/health
HTTP/1.1 401
WWW-Authenticate: Bearer realm="null", error="unauthorized", error_description="Full authentication is required to access this resource"
...

{"error":"unauthorized","error_description":"Full authentication is required to access this resource"}

この動きがSpring Boot 1.5から改善され、

  • sensitiveなエンドポイント(デフォルトだと/health/info 以外)はBasic認証

    $ curl -s -D - http://localhost:8080/env
    HTTP/1.1 401 
    WWW-Authenticate: Basic realm="Spring"
    ....
    
    {"timestamp":1484460898978,"status":401,"error":"Unauthorized","message":"Full authentication is required to access this resource","path":"/env"}
    
  • sensitiveでないエンドポイント(デフォルトだと/health/info)は認証なし

    $ curl -s -D - http://localhost:8080/health
    HTTP/1.1 200 
    ...
    
    {"status":"UP"}
    
  • ユーザ定義のリソースのエンドポイント(デフォルトだと上記以外)はOAuth2認証(アクセストークン認証)

    $ curl -s -D - http://localhost:8080/hello
    HTTP/1.1 401 
    WWW-Authenticate: Bearer realm="null", error="unauthorized", error_description="Full authentication is required to access this resource"
    ....
    
    {"error":"unauthorized","error_description":"Full authentication is required to access this resource"}
    

でアクセスできるようになります。

これは・・・Spring Securityの認証・認可の設定を適用する順序が関係しており、Spring 1.4では「Spring Security OAuth2 → Spring Boot Actuator」の順だったのが・・・Spring Boot 1.5から「Spring Boot Actuator → Spring Security OAuth2」の順で適用されるように改善されています。
なお、Spring Boot 1.4と同じ動きにしたい場合は、Spring Security OAuth2側のコンフィギュレーションの適用順をプロパティファイルで変更することで実現することができます。

src/main/resources/application.properties
security.oauth2.resource.filter-order=3

New and Noteworthy

Spring Boot 1.5からの新機能や改善系の主な変更点は以下の通りです。

Note:

Spring Boot 1.5でのプロパティキーの追加・廃止・非推奨の状況については、「Spring Boot 1.5 Configuration Changelog」を参照してください。

Third-party library upgrades

3rdパーティ製のライブラリやMavenプラグインなどのバージョンが更新されています。

具体的には・・・

  • Spring Data Ingalls
  • Jetty 9.4
  • JooQ 3.9
  • AssertJ 2.6.0
  • Hikari 2.5
  • Neo4J 2.1
  • etc ..

です。

Loggers endpoint

Spring Actuatorに「ロガーの確認とログレベルを変更するためのエンドポイント(/loggers)」が追加されました。

具体的には・・・

  • ロガーの一覧確認用の「GET /loggers
  • 特定のロガーの確認用の「GET /loggers/{ロガー名}
  • 特定のロガーのログレベル変更用の「POST /loggers/{ロガー名}

が用意されています。

では、実際にcom.exampleのログレベルの確認と変更をしてみましょう。本来は認可制御すべきですが、ここでは動作確認用に認可制御を無効化(management.security.enabled=false)した状態でアクセスします。

ログレベルの確認
$ curl -s http://localhost:8080/loggers/com.example
{"configuredLevel":null,"effectiveLevel":"INFO"}
ログレベルの更新(未指定(INFO)->DEBUGへ)
$ curl -s http://localhost:8080/loggers/com.example -X POST -H "Content-Type: application/json" -d '{"configuredLevel": "DEBUG"}'
変更後のログレベルの確認
$ curl -s http://localhost:8080/loggers/com.example
{"configuredLevel":"DEBUG","effectiveLevel":"DEBUG"}

Note:

ちなみに・・・更新時に指定するログレベルは大文字じゃないとIllegalArgumentExceptionが発生します :disappointed_relieved: これはバグっっぽいのでPull Request(spring-boot#gh-7914)してみました。

2017/1/22 追記
Pull Requestがマージされたので↑の問題は1.5.0.RELEASEで解消されます。

こちらも・・・ @making@github のブログ「Cloud Foundry :hearts: Spring Boot」の中で、PCF(Pivotal Cloud Foundry)との連携という切り口で紹介されています!!

Apache Kafka support

Spring Boot 1.5から、Spring for Apache Kafka向けの自動コンフィギュレーションがサポートされました。

Note:

Apache Kafkaは・・・2011年にLinkedInから公開されたオープンソースの分散メッセージングシステムで、ウェブサービスなどから発せられる大容量のデータ(例:ログやイベント)を高スループット/低レイテンシに収集/配信することを目的に開発されているようです。なお、ここではApache KafkaやSpring Kafkaの説明や使い方の説明は割愛します。

依存アーティファクトにspring-kafkaを追加し、

pom.xml
<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

必要に応じて、spring-kafka用のプロパティ(spring.kafka.*)を行えば、Apache Kafkaを介したメッセージ連携が行えるようになります。もちろん・・・Kafka Cluster(Broker)の起動が別途必要ですが・・・:sweat_smile:

src/main/resources/application.properties
# APACHE KAFKA (KafkaProperties)
spring.kafka.bootstrap-servers= # Comma-delimited list of host:port pairs to use for establishing the initial connection to the Kafka cluster.
spring.kafka.client-id= # Id to pass to the server when making requests; used for server-side logging.
spring.kafka.consumer.auto-commit-interval= # Frequency in milliseconds that the consumer offsets are auto-committed to Kafka if 'enable.auto.commit' true.
spring.kafka.consumer.auto-offset-reset= # What to do when there is no initial offset in Kafka or if the current offset does not exist any more on the server.
spring.kafka.consumer.bootstrap-servers= # Comma-delimited list of host:port pairs to use for establishing the initial connection to the Kafka cluster.
spring.kafka.consumer.client-id= # Id to pass to the server when making requests; used for server-side logging.
spring.kafka.consumer.enable-auto-commit= # If true the consumer's offset will be periodically committed in the background.
spring.kafka.consumer.fetch-max-wait= # Maximum amount of time in milliseconds the server will block before answering the fetch request if there isn't sufficient data to immediately satisfy the requirement given by "fetch.min.bytes".
spring.kafka.consumer.fetch-min-size= # Minimum amount of data the server should return for a fetch request in bytes.
spring.kafka.consumer.group-id= # Unique string that identifies the consumer group this consumer belongs to.
spring.kafka.consumer.heartbeat-interval= # Expected time in milliseconds between heartbeats to the consumer coordinator.
spring.kafka.consumer.key-deserializer= # Deserializer class for keys.
spring.kafka.consumer.max-poll-records= # Maximum number of records returned in a single call to poll().
spring.kafka.consumer.value-deserializer= # Deserializer class for values.
spring.kafka.listener.ack-count= # Number of records between offset commits when ackMode is "COUNT" or "COUNT_TIME".
spring.kafka.listener.ack-mode= # Listener AckMode; see the spring-kafka documentation.
spring.kafka.listener.ack-time= # Time in milliseconds between offset commits when ackMode is "TIME" or "COUNT_TIME".
spring.kafka.listener.concurrency= # Number of threads to run in the listener containers.
spring.kafka.listener.poll-timeout= # Timeout in milliseconds to use when polling the consumer.
spring.kafka.producer.acks= # Number of acknowledgments the producer requires the leader to have received before considering a request complete.
spring.kafka.producer.batch-size= # Number of records to batch before sending.
spring.kafka.producer.bootstrap-servers= # Comma-delimited list of host:port pairs to use for establishing the initial connection to the Kafka cluster.
spring.kafka.producer.buffer-memory= # Total bytes of memory the producer can use to buffer records waiting to be sent to the server.
spring.kafka.producer.client-id= # Id to pass to the server when making requests; used for server-side logging.
spring.kafka.producer.compression-type= # Compression type for all data generated by the producer.
spring.kafka.producer.key-serializer= # Serializer class for keys.
spring.kafka.producer.retries= # When greater than zero, enables retrying of failed sends.
spring.kafka.producer.value-serializer= # Serializer class for values.
spring.kafka.properties.*= # Additional properties used to configure the client.
spring.kafka.ssl.key-password= # Password of the private key in the key store file.
spring.kafka.ssl.keystore-location= # Location of the key store file.
spring.kafka.ssl.keystore-password= # Store password for the key store file.
spring.kafka.ssl.truststore-location= # Location of the trust store file.
spring.kafka.ssl.truststore-password= # Store password for the trust store file.
spring.kafka.template.default-topic= # Default topic to which messages will be sent.

Cloud Foundry actuator extensions

Spring Boot 1.5から、Spring BootのActuator機能とCloud Foundryの運用系機能(管理コンソールとか)との連携機能が強化されています。 こちらについては、@making@github のブログ「Cloud Foundry :hearts: Spring Boot」のみるのが一番わかりやすいと思います。

少しだけ補足すると・・・Spring BootアプリをCloud Foundryのインスタンス上にデプロイすると・・・「/cloudfoundryapplicationという特殊なエンドポイント(外部からアクセスできないエンドポイント)」が公開され、Cloud Foundryの運用系機能がそのエンドポイントを介してSpring Bootアプリの状態確認・変更が行える仕組みになっています。そのため、Actuator用のエンドポイントに対して認可制御がかかっている状態でも、Cloud Foundryの運用系機能からはアクセスできるというわけです。

Note:

ちなみに・・・現時点でSpring BootのActuator機能と連携したUI提供を行っているのはPivotal Cloud Foundryだけのようですが、Spring Boot側の実装がPivotal Cloud Foundryを意識しているわけではないので、Pivotal Cloud Foundry以外のCloud Foundry上でも同じようなことを実現することは論理的には可能です。

LDAP support

Spring Boot 1.5から、「LDAP連携用のStarter(spring-boot-starter-data-ldap)とspring-data-ldap向けの自動コンフィギュレーションの仕組み」がサポートされました。また、組み込みのインメモリLDAPとして「UnboundedID」の自動コンフィギュレーションもサポートされています。

依存アーティファクトにspring-boot-starter-data-ldapcom.unboundid:unboundid-ldapsdkを追加し、

pom.xml
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-ldap</artifactId>
</dependency>

<dependency> <!-- 組み込みLDAPを使う場合のみ -->
    <groupId>com.unboundid</groupId>
    <artifactId>unboundid-ldapsdk</artifactId>
</dependency>

必要に応じて、spring-data-ldap用のプロパティ(spring.ldap.*)を行えば、LDAPを介したデータ連携が行えるようになります。

src/main/resources/application.properties
# SPRING LDAP (LdapProperties)
spring.ldap.urls= # LDAP url of the server.
spring.ldap.base= # Base suffix from which all operations should originate.
spring.ldap.username= # Login user of the server.
spring.ldap.password= # Login password of the server.
spring.ldap.base-environment.*= # Ldap specification settings.

# EMBEDDED LDAP (EmbeddedLdapProperties)
spring.ldap.embedded.port= # Embedded LDAP port.
spring.ldap.embedded.credential.username= # Embedded LDAP username.
spring.ldap.embedded.credential.password= # Embedded LDAP password.
spring.ldap.embedded.base-dn= # The base DN
spring.ldap.embedded.ldif= # Schema (LDIF) script resource reference.

Note:

ちなみに・・・組み込みLDAPを使う場合は、spring.ldap.embedded.base-dnに値を指定しないと自動コンフィギュレーションされません。

AuditEvents Endpoint Support

Spring Boot 1.5から、認証・認可の成功・失敗イベントがSpring MVCのエンドポイント(/auditevents)とJMXのMBeanを介して参照できるようになります。
以下は、Spring MVCのエンドポイントを介して取得できるJSON例です。

{
  "events": [
    {
      "timestamp": "2017-01-09T04:57:41+0000",
      "principal": "anonymousUser",
      "type": "AUTHORIZATION_FAILURE",
      "details": {
        "remoteAddress": "0:0:0:0:0:0:0:1",
        "sessionId": null
      },
      "type": "org.springframework.security.access.AccessDeniedException",
      "message": "Access is denied"
    },
    {
      "timestamp": "2017-01-09T04:57:46+0000",
      "principal": "a",
      "type": "AUTHENTICATION_FAILURE",
      "details": {
        "remoteAddress": "0:0:0:0:0:0:0:1",
        "sessionId": null
      },
      "type": "org.springframework.security.authentication.BadCredentialsException",
      "message": "Bad credentials"
    },
    {
      "timestamp": "2017-01-09T04:57:54+0000",
      "principal": "user",
      "type": "AUTHENTICATION_SUCCESS",
      "details": {
        "remoteAddress": "0:0:0:0:0:0:0:1",
        "sessionId": null
      }
    }
  ]
}

Note:

Spring Boot 1.4でも認証・認可の成功・失敗イベント自体は記録されていたみたいですが、情報を公開するためのエンドポイントが提供されていなかったみたいです。でも、なぜMVCのエンドポイントの紹介はないのだろ・・・と思ったので、RC1のリリースアナウンスのBLOGにコメントしてみました。

2017/01/11 追記
MVCのエンドポイントもリリースノートで紹介されるようになりました!!(なので・・・内容も一部変更しました)

Transaction manager properties

Spring Boot 1.5から、自動コンフィギュレーションされたPlatformTransactionManagerに対して、以下のプロパティを使用してカスタマイズすることができます。

  • デフォルトのトランザクションタイムアウト時間(秒)
  • コミット時にエラーが発生した際にロールバック処理を行うか否かのフラグ(デフォルト値はfalse=ロールバックメソッドは呼び出さない)
src/main/resources/application.properties
# TRANSACTION (TransactionProperties)
spring.transaction.default-timeout= # Default transaction timeout in seconds.
spring.transaction.rollback-on-commit-failure= # Perform the rollback on commit

Note:

この対応と同時に・・・PlatformTransactionManagerをカスタマイズする仕組みが導入されているので、興味がある方は「Spring Boot 1.5からPlatformTransactionManager用のCustomizerが追加される」をご覧ください。

JmxEndpoint interface

Spring Boot 1.5から、ActuatorのJMX用エンドポイントを公開するためのorg.springframework.boot.actuate.endpoint.jmx.JmxEndpointインタフェースが追加され、開発者はこのインタフェースを実装してDIコンテナに登録するだけでJMXサーバ上にMBeanを登録することができます。
これは、Spring MVC向けのエンドポイントを公開する時に使うorg.springframework.boot.actuate.endpoint.mvc.MvcEndpointと同等の役割をもつインタフェースです。

極端な話・・・以下のようなBean定義を行うだけで、JMX上にMBeanを登録することもできます。

@Bean
JmxEndpoint fooJmxEndpoint(){
    return new JmxEndpoint() {
        @Override
        public boolean isEnabled() {
            return true;
        }

        @Override
        public String getIdentity() {
            return null;
        }

        @Override
        public Class<? extends Endpoint> getEndpointType() {
            return null;
        }
    };
}

Spring MVCのエンドポイントも・・・以下のようなBean定義を行うだけでWeb上に公開することができ、以下の例だとGET /fooにアクセスするとfooという文字列がレスポンスされます。

@Bean
MvcEndpoint fooMvcEndpoint() {
    return new MvcEndpoint() {
        @Override
        public String getPath() {
            return "/foo";
        }

        @Override
        public boolean isSensitive() {
            return false;
        }

        @Override
        public Class<? extends Endpoint> getEndpointType() {
            return null;
        }

        @GetMapping
        @ResponseBody
        public String get(){
            return "foo";
        }
    };
}

Vendor specific flyway migrations

Spring Boot 1.5から、Flywayを使ったデータベースのマイグレーション用スクリプトを、データベースのベンダー毎に用意できるようになります。
この仕組みを使う場合は、スクリプトファイルを読み込むロケーションの中に{vendor}というプレースホルダーを指定してください。

src/main/resources/application.properties
flyway.locations=db/migration/{vendor}
.
└── src
    └── main
        └── resources
            ├── application.properties
            └── db
                └── migration
                    ├── h2
                    │   └── V1_0_0_00__schema.sql
                    └── oracle
                        └── V1_0_0_00__schema.sql

この仕組みは、使用するデータベースを選択できるようなアプリケーションを作る場合に便利ですね。

Testing updates

Spring Boot 1.5から、テスト用の自動コンフィギュレーションを有効にするためのアノテーション(@JsonTest, @WebMvcTest, @DataJpaTest, @JdbcTest, @RestClientTest)にて、指定した自動コンフィギュレーション用のクラスを除外するための属性(excludeAutoConfiguration)が追加されました。

@RunWith(SpringRunner.class)
@SpringBootTest
@WebMvcTest(excludeAutoConfiguration = HttpMessageConvertersAutoConfiguration.class) // Spring 1.5+
//@ImportAutoConfiguration(exclude = HttpMessageConvertersAutoConfiguration.class) // Spring 1.4以前
public class FooTests {
    // ...
}

なお、@JdbcTestはSpring Boot 1.5から追加されたアノテーションです。

Custom fat jar layouts

Spring Boot 1.5から、Spring Boot MavenとGradleプラグインを使って独自のjarレイアウトを導入できるようになったみたいです。このこの仕組みの導入により、spring-boot-thin-launcherのような(実験的な)jarレイアウトを開発することができるようになるとのことです。

JmsTemplate customizations

Spring Boot 1.5から、自動コンフィギュレーションされたJmsTemplateに対して、以下のプロパティを使用してカスタマイズすることができます。

src/main/resources/application.properties
# JMS (JmsProperties)
# ...
spring.jms.template.default-destination= # Default destination to use on send/receive operations that do not have a destination parameter.
spring.jms.template.delivery-delay= # Delivery delay to use for send calls in milliseconds.
spring.jms.template.delivery-mode= # Delivery mode. Enable QoS when set.
spring.jms.template.priority= # Priority of a message when sending. Enable QoS when set.
spring.jms.template.qos-enabled= # Enable explicit QoS when sending a message.
spring.jms.template.receive-timeout= # Timeout to use for receive calls in milliseconds.
spring.jms.template.time-to-live= # Time-to-live of a message when sending in milliseconds. Enable QoS when set.

Miscellaneous

その他、雑多な変更点は以下の通りです。

  • Mockito 2.xで@MockBeanが使えるようになる。

  • Fully Executable Jar/Warの組み込みスクリプトにて、強制停止(force-stop)オプションがサポートされる。

  • Cassandraのヘルスチェックがサポートされる。

  • Cassandraのユーザ定義の型がSpring DataのSimpleUserTypeResolverを介して解決できるようになる。

  • Spring Boot Maven Pluginのskipプロパティが、runstoprepackageで動作するようになる。

  • 複数のメインメソッドクラスが見つかった場合、MavenとGradleのSpring BootPluginは自動的に@SpringBootApplicationアノテーションが付与されているクラスを使用するようになる。

Deprecations in Spring Boot 1.5

いくつか非推奨となるAPIやプロパティがあるので、必要に応じて修正しよう!

  • TomcatEmbeddedServletContainerFactorysetTldSkipメソッドが非推奨になるため、代わりにsetTldSkipPatternsを使うようにする。

  • ApplicationStartedEventは非推奨になるため、 代わりにApplicationStartingEventを使うようにする。

  • LoggingApplicationListenerに定義していた定数(PATH_PROPERTYFILE_PROPERTY)が非推奨になるため、代わりにLogFileの定数を使うようにする。

  • Cacheの実装としてGuavaが非推奨になるため、代わりにCaffeineへの移行を検討する必要がある。なお、GuavaはSpring Frameowrk 5でサポート機能が完全に削除されます。

  • CRaSHを使用してSpring BootアプリケーションにSSHでアクセスする機能が非推奨になるため、運用ツールなどでこの機能を使っている場合は別の仕組みへの移行を検討する必要がある。

  • JmxEndpointの導入に伴い、EndpointMBeanExporterのいくつかのprotectedメソッドが非推奨になるため、JmxEndpoint又はadaptEndpointメソッドを使ってJMXサーバ上にMBeanを登録するようにする。

  • SearchStrategy#PARENTSが非推奨になるため、SearchStrategy#ANCESTORSを使うようにする。

  • Apache Commons DBCPが非推奨になるため、Apache Commons DBCP 2又は他のコネクションプーリングを使うようにする。

  • Undertow内部で使われていないため(UNDERTOW-587)、Undertow用のプロパティ(server.undertow.buffers-per-region)が非推奨になる。

  • @AutoConfigureTestDatabaseのパッケージがorg.springframework.boot.test.autoconfigure.orm.jpaからorg.springframework.boot.test.autoconfigure.jdbcされるため、新しいパッケージに移動になったアノテーションを使うようにする。

Property Renames

いくつかのプロパティの名前が変更・削除されます。

  • server.max-http-post-sizeプロパティは、サーバ固有のプロパティ(例: server.tomcat.max-http-post-size)に変更される。これはサーバによって扱う型(int vs long)が異なるからみたいです。

  • Spring Data Neo4Jのバージョンアップに伴い、spring.data.neo4j.session.scopeプロパティが削除されます。

まとめ

リリースノートベースなので他にもたくさん変更点があると思いますが・・・メインどころの変更点は抑えられていると思います。なお、英語にあまり自信がないので・・・誤釈があるかもしれません。へんなところあったらコメントお願いしま〜す :sweat_smile:

参考サイト