Vad är nytt i Spring Boot 2?

1. Översikt

Spring Boot ger en uppfattning om vårens ekosystem. Släpptes först i mitten av 2014. Spring Boot har genomgått mycket utveckling och förbättringar. Version 2.0 är idag redo att släppas i början av 2018.

Det finns olika områden där detta populära bibliotek försöker hjälpa oss:

  • Beroendehantering. Genom förrätter och olika integrationer av pakethanteraren
  • Autokonfiguration. Att försöka minimera mängden konfiguration som en Spring-app kräver för att göra dig redo att gå och gynna konventionen framför konfigurationen
  • Produktionsfärdiga funktioner. Såsom ställdon , bättre loggning, övervakning, mått eller olika PAAS-integration
  • Förbättrad utvecklingserfarenhet. Med flera testverktyg eller en bättre feedback loop med spring-boot-devtools

I den här artikeln kommer vi att undersöka några ändringar och funktioner som planeras för Spring Boot 2.0. Vi beskriver också hur dessa förändringar kan hjälpa oss att bli mer produktiva.

2. Beroenden

2.1. Java-baslinje

Spring Boot 2.x stöder inte längre Java 7 och senare , eftersom Java 8 är minimikravet.

Det är också den första versionen som stöder Java 9. Det finns inga planer på att stödja Java 9 på 1.x-grenen. Det betyder att om du vill använda den senaste Java-versionen och dra nytta av detta ramverk är Spring Boot 2.x ditt enda alternativ .

2.2. Bill of Materials

Med varje ny version av Spring Boot uppgraderas versioner av olika beroenden i Java-ekosystemet. Detta definieras i Boot bill of materials aka BOM .

I 2.x är detta inget undantag. Det är ingen mening att lista dem, men vi kan titta på spring-boot-dependencies.pom för att se vilka versioner som används vid en viss tidpunkt.

Några höjdpunkter angående minsta möjliga versioner:

  • Tomcats minsta stödda version är 8,5
  • Hibernate minimum version som stöds är 5.2
  • Gradle minsta version som stöds är 3.4

2.3. Gradle Plugin

Gradle-insticksprogrammet har genomgått stora förbättringar och en del brytande förändringar.

För att skapa fettburkar ersätts bootRepackage Gradles uppgift med bootJar och bootWar för att bygga burkar respektive krig.

Om vi ​​ville köra våra appar med Gradle-plugin, i 1.x, kunde vi köra gradle bootRun. I 2.x utökas bootRun Gradles JavaExec. Detta innebär att det är lättare för oss att konfigurera det med samma konfiguration som vi vanligtvis använder i klassiska JavaExec- uppgifter.

Ibland befinner vi oss i att vilja dra nytta av Spring Boot BOM. Men ibland vill vi inte bygga en fullständig Boot-app eller packa om den.

I det avseendet är det intressant att veta att Spring Boot 2.x inte längre kommer att använda plugin för beroendeshantering som standard .

Om vi ​​vill ha Spring Boot-beroendehantering bör vi lägga till:

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

Detta ger oss större flexibilitet med mindre konfiguration i ovan nämnda scenario.

3. Autokonfiguration

3.1. säkerhet

I 2.x blir säkerhetskonfigurationen dramatiskt förenklad. Som standard är allt säkert, inklusive statiska resurser och ställdonsslutpunkter.

När användaren konfigurerar säkerheten uttryckligen kommer Spring Boot-standardvärden att sluta påverka. Användaren kan sedan konfigurera alla åtkomstregler på en enda plats.

Detta kommer att hindra oss från att kämpa med WebSecurityConfigurerAdapter beställningsproblem. Dessa problem uppstod vanligtvis när du konfigurerar säkerhetsregler för ställdon och appar på ett anpassat sätt.

Låt oss titta på ett enkelt säkerhetsavsnitt som blandar ställdon och applikationsregler:

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. Reaktivt stöd

Spring Boot 2 ger en uppsättning nya förrätter för olika reaktiva moduler. Några exempel är WebFlux och de reaktiva motsvarigheterna för MongoDB, Cassandra eller Redis.

Det finns också testverktyg för WebFlux. I synnerhet kan vi dra nytta av @WebFluxTest. Detta beter sig på samma sätt som det äldre @WebMvcTest som ursprungligen introducerades som en del av de olika testskivorna tillbaka i 1.4.0.

4. Produktionsfärdiga funktioner

Spring Boot ger några användbara verktyg som gör det möjligt för oss att skapa produktionsklara applikationer. Bland annat kan vi dra nytta av Spring Boot Actuator.

Ställdonet innehåller olika verktyg för att förenkla övervakning, spårning och allmän appintro. Mer information om ställdon finns i vår tidigare artikel.

Med sin 2-version har ställdonet genomgått stora förbättringar. Denna iteration fokuserar på att förenkla anpassningen. Den stöder också annan webbteknik, inklusive den nya reaktiva modulen.

4.1. Teknisk support

I Spring Boot 1.x stöddes endast Spring-MVC för ställdonens slutpunkter. I 2.x blev det dock oberoende och pluggbart. Spring boot ger nu stöd ur lådan för WebFlux, Jersey och Spring-MVC.

As before, JMX remains an option and can be enabled or disabled through configuration.

4.2. Creating Custom Endpoints

The new actuator infrastructure is technology-agnostic. Because of this, the development model has been redesigned from scratch.

The new model also brings greater flexibility and expressiveness.

Let's see how to create a Fruits endpoint for actuator:

@Endpoint(id = "fruits") public class FruitsEndpoint { @ReadOperation public Map fruits() { ... } @WriteOperation public void addFruits(@Selector String name, Fruit fruit) { ... } }

Once we register FruitsEndpoint in our ApplicationContext, it can be exposed as a web endpoint using our chosen technology. We could also expose it via JMX depending on our configuration.

Translating our endpoint to web endpoints, this would result in:

  • GET on /application/fruits returning fruits
  • POST on /applications/fruits/{a-fruit} handling that fruit which should be included in the payload

There are many more possibilities. We could retrieve more granular data. Also, we could define specific implementations per underlying technology (e.g., JMX vs. Web). For the purpose of the article, we'll keep it as a simple introduction without getting into too much detail.

4.3. Security in Actuator

In Spring Boot 1.x Actuator defines its own security model. This security model is different from the one used by our application.

This was the root of many pain points when users were trying to refine security.

In 2.x the security configuration should be configured using the same config that the rest of the application uses.

By default, most actuator endpoints are disabled. This is independent of whether Spring Security is in the classpath or not. Beyond status and info, all the other endpoints need to be enabled by the user.

4.4. Other Important Changes

  • Most configuration properties are now under management.xxx e.g.: management.endpoints.jmx
  • Some endpoints have a new format. e.g.: env, flyway or liquibase
  • Predefined endpoint paths are no longer configurable

5. Enhanced Development Experience

5.1. Better Feedback

Spring boot introduced devtools in 1.3.

It takes care of smoothing out typical development issues. For example, caching of view technologies. It also performs automatic restarts and browser live-reloading. Also, it enables us to remote debug apps.

In 2.x when our application gets restarted by devtools a ‘delta' report will be printed out. This report will point out what changed and the impact it might have on our application.

Let's say we define a JDBC Datasource overriding the one configured by Spring Boot.

Devtools will indicate that the one autoconfigured is no longer created. It will also point out the cause, an adverse match in @ConditionalOnMissingBean for type javax.sql.DataSource. Devtools will print this report once it performs a restart.

5.2. Breaking Changes

Due to JDK 9 issues, devtools is dropping support for remote debugging through HTTP.

6. Summary

In this article, we covered some of the changes that Spring Boot 2 will bring.

We discussed dependencies and how Java 8 becomes the minimum supported version.

Next, we talked about autoconfiguration. We focused on security among others. We also talked about actuator and the many improvements it has received.

Lastly, we talked about some minor tweaks that happened in the development tools provided.