streamalism.org

1. Overzicht

Spring Boot brengt een eigenzinnige benadering van het Spring-ecosysteem. Voor het eerst uitgebracht medio 2014. Spring Boot heeft veel ontwikkeling en verbetering doorgemaakt. Versie 2.0 maakt zich vandaag klaar voor release begin 2018.

Er zijn verschillende gebieden waar deze populaire bibliotheek ons ​​probeert te helpen:

• Beheer van afhankelijkheden. Door middel van starters en verschillende pakketbeheerder integraties
• Automatische configuratie. Probeer de hoeveelheid configuratie die een Spring-app nodig heeft te minimaliseren om klaar te zijn voor gebruik en voorkeur te geven aan conventie boven configuratie
• Productieklare functies. Zoals Actuator, betere logboekregistratie, monitoring, metrische gegevens of verschillende PAAS-integratie
• Verbeterde ontwikkelervaring. Met meerdere testhulpprogramma's of een betere feedbacklus met behulp van spring-boot-devtools

In dit artikel bespreken we enkele wijzigingen en functies die zijn gepland voor Spring Boot 2.0. We zullen ook beschrijven hoe deze wijzigingen ons kunnen helpen productiever te worden.

2. Afhankelijkheden

2.1. Java-basislijn

Spring Boot 2.x ondersteunt niet langer Java 7 en lager, zijnde Java 8 de minimumvereiste.

Het is ook de eerste versie die Java 9 ondersteunt. Er zijn geen plannen om Java 9 op de 1.x-tak te ondersteunen. Dit betekent Als u de laatste Java-uitgave wilt gebruiken en van dit framework wilt profiteren, is Spring Boot 2.x uw enige optie.

2.2. Stuklijst

Bij elke nieuwe release van Spring Boot worden versies van verschillende afhankelijkheden van het Java-ecosysteem geüpgraded. Dit wordt gedefinieerd in Boot stuklijst aka Stuklijst.

In 2.x is dit geen uitzondering. Het heeft geen zin om ze op te sommen, maar we kunnen er wel naar kijken spring-boot-dependencies.pom om te zien welke versies op een bepaald moment in de tijd worden gebruikt.

Een paar hoogtepunten met betrekking tot de minimaal vereiste versies:

• De minimaal ondersteunde versie van Tomcat is 8.5
• Minimaal ondersteunde versie voor sluimerstand is 5.2
• De minimaal ondersteunde versie van Gradle is 3.4

2.3. Gradle-plug-in

De Gradle-plug-in heeft grote verbeteringen ondergaan en enkele belangrijke wijzigingen ondergaan.

Om vetpotten te maken, bootRepackage Gradle's taak wordt vervangen door bootJar en bootWar om respectievelijk potten en oorlogen te bouwen.

Als we onze apps wilden uitvoeren met de Gradle-plug-in, in 1.x, zouden we gradle bootRun.In 2.x bootRun breidt Gradle's uit JavaExec. Dit houdt in dat het voor ons gemakkelijker is om het te configureren door dezelfde configuratie toe te passen die we normaal gesproken in klassiek zouden gebruiken JavaExec taken.

Soms merken we dat we willen profiteren van Spring Boot BOM. Maar soms willen we geen volledige Boot-app bouwen of deze opnieuw verpakken.

In dit verband is het interessant dat te weten Spring Boot 2.x zal de plug-in voor afhankelijkheidsbeheer niet langer standaard toepassen.

Als we Spring Boot-afhankelijkheidsbeheer willen, moeten we toevoegen:

pas plug-in toe: 'io.spring.dependency-management'

Dit geeft ons meer flexibiliteit met minder configuratie in het bovengenoemde scenario.

3. Automatische configuratie

3.1. Veiligheid

In 2.x wordt de beveiligingsconfiguratie drastisch vereenvoudigd. Standaard is alles beveiligd, inclusief statische bronnen en Actuator-eindpunten.

Zodra de gebruiker de beveiliging expliciet heeft geconfigureerd, hebben de Spring Boot-standaardinstellingen geen invloed meer. De gebruiker kan vervolgens alle toegangsregels op één plek configureren.

Dit zal voorkomen dat we ermee worstelen WebSecurityConfigurerAdapter bestelproblemen. Deze problemen deden zich gewoonlijk voor bij het configureren van actuator- en app-beveiligingsregels op een aangepaste manier.

Laten we eens kijken naar een eenvoudig beveiligingsfragment dat actuator- en toepassingsregels combineert:

http.authorizeRequests () .requestMatchers (EndpointRequest.to ("health")) .permitAll () // Actuatorregels per eindpunt .requestMatchers (EndpointRequest.toAnyEndpoint ()) .hasRole ("admin") // Actuator algemene regels .requestMatchers (PathRequest.toStaticResources (). AtCommonLocations ()) .permitAll () // Statische bronbeveiliging .antMatchers ("/ **") .hasRole ("gebruiker") // Toepassingsbeveiligingsregels // ...

3.2. Reactieve ondersteuning

Spring Boot 2 brengt een reeks nieuwe starters voor verschillende reactieve modules. Enkele voorbeelden zijn WebFlux en de reactieve tegenhangers voor MongoDB, Cassandra of Redis.

Er zijn ook testhulpprogramma's voor WebFlux. In het bijzonder kunnen we profiteren van @WebFluxTest. Dit gedraagt ​​zich op dezelfde manier als de oudere @WebMvcTest oorspronkelijk geïntroduceerd als onderdeel van de verschillende testen plakjes terug in 1.4.0.

4. Productieklare functies

Spring Boot biedt een aantal handige tools waarmee we productieklare applicaties kunnen maken. We kunnen onder andere profiteren van Spring Boot Actuator.

Actuator bevat verschillende tools voor het vereenvoudigen van monitoring, tracering en algemene app-introspectie. Meer informatie over de actuator vindt u in ons vorige artikel.

Met zijn 2 versie aandrijving heeft grote verbeteringen ondergaan. Deze iteratie is gericht op het vereenvoudigen van maatwerk. Het ondersteunt ook andere webtechnologieën, waaronder de nieuwe reactieve module.

4.1. Technologie ondersteuning

In Spring Boot 1.x werd alleen Spring-MVC ondersteund voor actuator-eindpunten. In 2.x werd het echter onafhankelijk en pluggable. Spring-boot biedt nu ondersteuning uit de doos voor WebFlux, Jersey en Spring-MVC.

Net als voorheen blijft JMX een optie en kan via configuratie worden in- of uitgeschakeld.

4.2. Aangepaste eindpunten maken

De nieuwe actuatorinfrastructuur is technologie-agnostisch. Daarom is het ontwikkelmodel helemaal opnieuw ontworpen.

Het nieuwe model zorgt ook voor meer flexibiliteit en zeggingskracht.

Laten we eens kijken hoe we een Fruit eindpunt voor actuator:

@Endpoint (id = "fruits") openbare klasse FruitsEndpoint {@ReadOperation openbare kaart fruits () {...} @WriteOperation openbare leegte addFruits (@Selector String-naam, Fruitfruit) {...}}

Zodra we ons registreren FruitsEndpoint in onze Toepassingscontext, het kan worden weergegeven als een web-eindpunt met behulp van de door ons gekozen technologie. We zouden het ook kunnen blootstellen via JMX, afhankelijk van onze configuratie.

Het vertalen van ons eindpunt naar web-eindpunten, zou resulteren in:

• KRIJGEN Aan / applicatie / fruit terugkerende vruchten
• POST Aan / applications / fruits / {a-fruit} het hanteren van dat fruit dat in de payload moet worden opgenomen

Er zijn veel meer mogelijkheden. We zouden gedetailleerdere gegevens kunnen ophalen. We zouden ook specifieke implementaties kunnen definiëren per onderliggende technologie (bijvoorbeeld JMX vs. web). Voor de toepassing van het artikel houden we het als een eenvoudige inleiding zonder al te gedetailleerd in te gaan.

4.3. Beveiliging in Actuator

In Spring Boot definieert 1.x Actuator zijn eigen beveiligingsmodel. Dit beveiligingsmodel verschilt van het model dat door onze applicatie wordt gebruikt.

Dit was de oorzaak van veel pijnpunten wanneer gebruikers de beveiliging probeerden te verfijnen.

In 2.x moet de beveiligingsconfiguratie worden geconfigureerd met dezelfde configuratie die de rest van de applicatie gebruikt.

Standaard zijn de meeste actuator-eindpunten uitgeschakeld. Dit is onafhankelijk van het feit of Spring Security zich in het klassenpad bevindt of niet. Voorbij toestand en info, alle andere eindpunten moeten worden ingeschakeld door de gebruiker.

4.4. Andere belangrijke wijzigingen

• De meeste configuratie-eigenschappen zijn nu onder management.xxx bijv .: management.endpoints.jmx
• Sommige eindpunten hebben een nieuw formaat. bijv .: env, flyway of liquibase
• Vooraf gedefinieerde eindpuntpaden zijn niet langer configureerbaar

5. Verbeterde ontwikkelervaring

5.1. Betere feedback

Spring boot geïntroduceerd devtools in 1.3.

Het zorgt voor het gladstrijken van typische ontwikkelingsproblemen. Bijvoorbeeld caching van weergavetechnologieën. Het voert ook automatische herstarts uit en de browser wordt live opnieuw geladen. Het stelt ons ook in staat apps op afstand te debuggen.

In 2.x wanneer onze applicatie opnieuw wordt opgestart door devtools er wordt een ‘delta'-rapport afgedrukt. Dit rapport zal aangeven wat er is veranderd en de impact die dit kan hebben op onze applicatie.

Stel dat we een JDBC-gegevensbron definiëren die de door Spring Boot geconfigureerde gegevensbron vervangt.

Devtools geeft aan dat degene die automatisch is geconfigureerd niet langer wordt gemaakt. Het zal ook wijzen op de oorzaak, een ongunstige match in @ConditionalOnMissingBean voor type javax.sql.DataSource. Devtools zal dit rapport afdrukken zodra het een herstart uitvoert.

5.2. Veranderingen doorbreken

Vanwege JDK 9-problemen laat devtools de ondersteuning voor foutopsporing op afstand via HTTP vallen.

6. Samenvatting

In dit artikel hebben we enkele van de veranderingen besproken die Spring Boot 2 met zich meebrengt.

We hebben de afhankelijkheden besproken en hoe Java 8 de minimaal ondersteunde versie wordt.

Vervolgens hadden we het over autoconfiguratie. We hebben ons onder meer gefocust op beveiliging. We hebben ook gesproken over de actuator en de vele verbeteringen die deze heeft ondergaan.

Ten slotte hebben we het gehad over enkele kleine aanpassingen die zijn opgetreden in de meegeleverde ontwikkeltools.