streamalism.org

1. Oversikt

Spring Boot gir en meningsfylt tilnærming til vårens økosystem. Først utgitt i midten av 2014. Spring Boot har vært gjennom mye utvikling og forbedring. Versjonen 2.0 gjør seg i dag klar for utgivelse i begynnelsen av 2018.

Det er forskjellige områder der dette populære biblioteket prøver å hjelpe oss:

• Avhengighetsstyring. Gjennom forretter og ulike integrasjoner av pakkeleder
• Autokonfigurasjon. Å prøve å minimere mengden konfigurasjon som en Spring-app krever for å gjøre deg klar til å gå og favorisere konvensjonen fremfor konfigurasjonen
• Produksjonsklare funksjoner. Som for eksempel Aktuator, bedre logging, overvåking, beregninger eller forskjellige PAAS-integrasjoner
• Forbedret utviklingserfaring. Med flere testverktøy eller en bedre tilbakemeldingssløyfe ved hjelp av spring-boot-devtools

I denne artikkelen vil vi utforske noen endringer og funksjoner som er planlagt for Spring Boot 2.0. Vi beskriver også hvordan disse endringene kan hjelpe oss å bli mer produktive.

2. Avhengigheter

2.1. Java baseline

Spring Boot 2.x støtter ikke lenger Java 7 og nyere, er Java 8 minimumskravet.

Det er også den første versjonen som støtter Java 9. Det er ingen planer om å støtte Java 9 på 1.x-grenen. Dette betyr Hvis du vil bruke den nyeste Java-utgivelsen og dra nytte av dette rammeverket, er Spring Boot 2.x det eneste alternativet.

2.2. Stykklister

Med hver nye utgivelse av Spring Boot blir versjoner av forskjellige avhengigheter av Java-økosystemet oppgradert. Dette er definert i Boot stykklister aka BOM.

I 2.x er dette ikke noe unntak. Det gir ingen mening å liste dem opp, men vi kan se på det spring-boot-dependencies.pom for å se hvilke versjoner som brukes på et gitt tidspunkt.

Noen få høydepunkter angående minimumsversjoner:

• Tomcat minst støttede versjon er 8.5
• Dvalemodus som minimum støttes versjon er 5.2
• Gradle minimum støttet versjon er 3.4

2.3. Gradle Plugin

Gradle-pluginet har vært gjennom store forbedringer og noen ødeleggende endringer.

For å lage fettkrukker, bootRepackage Gradles oppgave blir erstattet med bootJar og bootWar å bygge henholdsvis krukker og kriger.

Hvis vi ønsket å kjøre appene våre med Gradle-plugin, i 1.x, kunne vi utføre gradle bootRun.I 2.x bootRun utvider Gradles JavaExec. Dette innebærer at det er lettere for oss å konfigurere det ved å bruke samme konfigurasjon som vi vanligvis bruker i klassisk JavaExec oppgaver.

Noen ganger finner vi at vi ønsker å dra nytte av Spring Boot BOM. Men noen ganger vil vi ikke bygge en full Boot-app eller pakke den om.

I denne forbindelse er det interessant å vite det Spring Boot 2.x bruker ikke lenger plugin for avhengighetsadministrasjon som standard.

Hvis vi vil ha Spring Boot avhengighetsadministrasjon, bør vi legge til:

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

Dette gir oss større fleksibilitet med mindre konfigurasjon i ovennevnte scenario.

3. Autokonfigurasjon

3.1. Sikkerhet

I 2.x blir sikkerhetskonfigurasjonen dramatisk forenklet. Som standard er alt sikret, inkludert statiske ressurser og aktuatorendepunkter.

Når brukeren konfigurerer sikkerheten eksplisitt, vil standardinnstillinger for Spring Boot ikke lenger påvirke. Brukeren kan deretter konfigurere alle tilgangsregler på ett sted.

Dette vil hindre oss i å slite med WebSecurityConfigurerAdapter bestillingsproblemer. Disse problemene pleide å skje vanligvis når du konfigurerer sikkerhetsregler for aktuator og app på en tilpasset måte.

La oss ta en titt på et enkelt sikkerhetsutdrag som blander aktuator- og applikasjonsregler:

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. Reaktiv støtte

Spring Boot 2 bringer et sett med nye forretter for forskjellige reaktive moduler. Noen eksempler er WebFlux, og de reaktive kolleger for MongoDB, Cassandra eller Redis.

Det er også testverktøy for WebFlux. Spesielt kan vi dra nytte av @WebFluxTest. Dette oppfører seg på samme måte som de eldre @WebMvcTest opprinnelig introdusert som en del av de forskjellige testene skiver tilbake i 1.4.0.

4. Produksjonsklare funksjoner

Spring Boot har noen nyttige verktøy som gjør det mulig for oss å lage produksjonsklare applikasjoner. Vi kan blant annet dra nytte av Spring Boot Actuator.

Aktuator inneholder forskjellige verktøy for å forenkle overvåking, sporing og generell introduksjon av apper. Ytterligere detaljer om aktuatoren finner du i vår forrige artikkel.

Med sin 2 versjon aktuator har vært gjennom store forbedringer. Denne iterasjonen fokuserer på å forenkle tilpasningen. Den støtter også andre webteknologier, inkludert den nye reaktive modulen.

4.1. Teknologisk støtte

I Spring Boot 1.x ble bare Spring-MVC støttet for aktuatorendepunkter. I 2.x ble det imidlertid uavhengig og pluggbart. Vårstøvel gir nå støtte ut av esken for WebFlux, Jersey og Spring-MVC.

Som før forblir JMX et alternativ og kan aktiveres eller deaktiveres gjennom konfigurasjon.

4.2. Opprette egendefinerte sluttpunkter

Den nye aktuatorinfrastrukturen er teknologi-agnostisk. På grunn av dette er utviklingsmodellen redesignet fra bunnen av.

Den nye modellen gir også større fleksibilitet og uttrykksevne.

La oss se hvordan du lager en Frukt endepunkt for aktuator:

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

Når vi registrerer oss FruktEndpoint i vår Søknadskontekst, den kan eksponeres som et nettendepunkt ved hjelp av vår valgte teknologi. Vi kan også eksponere den via JMX, avhengig av konfigurasjonen.

Hvis vi oversetter vårt endepunkt til nettendepunkter, vil dette resultere i:

• FÅ på / påføring / frukt returnerer frukt
• POST på / applikasjoner / frukt / {a-frukt} håndtering av frukten som skal inkluderes i nyttelasten

Det er mange flere muligheter. Vi kan hente mer detaljerte data. Vi kunne også definere spesifikke implementeringer per underliggende teknologi (f.eks. JMX vs. web). For formålet med artikkelen vil vi beholde det som en enkel introduksjon uten å komme i for mye detalj.

4.3. Sikkerhet i aktuator

I Spring Boot 1.x Actuator definerer sin egen sikkerhetsmodell. Denne sikkerhetsmodellen er forskjellig fra den som brukes av applikasjonen vår.

Dette var roten til mange smertepunkter når brukere prøvde å forfine sikkerheten.

I 2.x skal sikkerhetskonfigurasjonen konfigureres med den samme konfigurasjonen som resten av applikasjonen bruker.

Som standard er de fleste aktuatorendepunktene deaktivert. Dette er uavhengig av om vårsikkerhet er i klassestien eller ikke. Bortenfor status og info, alle de andre endepunktene må aktiveres av brukeren.

4.4. Andre viktige endringer

• De fleste konfigurasjonsegenskapene er nå under management.xxx f.eks .: management.endpoints.jmx
• Noen endepunkter har et nytt format. f.eks .: env, flyway eller liquibase
• Forhåndsdefinerte endepunktbaner kan ikke lenger konfigureres

5. Forbedret utviklingserfaring

5.1. Bedre tilbakemelding

Vårstøvel introdusert devtools i 1.3.

Den tar seg av utjevning av typiske utviklingsspørsmål. For eksempel caching av visningsteknologier. Den utfører også automatisk omstart og nettlesing på nytt. Det gjør det også mulig for oss å feilsøke apper.

I 2.x når søknaden vår startes om av devtools en 'delta' rapport vil bli skrevet ut. Denne rapporten vil peke på hva som har endret seg og hvilken innvirkning det kan ha på søknaden vår.

La oss si at vi definerer en JDBC-datakilde som overstyrer den som er konfigurert av Spring Boot.

Devtools vil indikere at den autokonfigurerte ikke lenger er opprettet. Det vil også påpeke årsaken, en negativ kamp i @ConditionalOnMissingBean for type javax.sql.DataSource. Devtools vil skrive ut denne rapporten når den starter på nytt.

5.2. Brytende endringer

På grunn av JDK 9-problemer slipper devtools støtte for ekstern feilsøking via HTTP.

6. Sammendrag

I denne artikkelen dekket vi noen av endringene som Spring Boot 2 vil medføre.

Vi diskuterte avhengigheter og hvordan Java 8 blir den minste støttede versjonen.

Deretter snakket vi om autokonfigurasjon. Vi fokuserte blant annet på sikkerhet. Vi snakket også om aktuatoren og de mange forbedringene den har fått.

Til slutt snakket vi om noen mindre justeringer som skjedde i utviklingsverktøyene som ble gitt.