Újdonságok a Spring Boot 2-ben?

1. Áttekintés

A Spring Boot véleményes megközelítést mutat be a tavaszi ökoszisztémában. Először 2014 közepén jelent meg. A Spring Boot sok fejlesztésen és fejlesztésen ment keresztül. A 2.0-s verziója ma készül megjelenni 2018 elején.

Különböző területeken próbál ez a népszerű könyvtár segítséget nyújtani nekünk:

  • Függőségkezelés. Indítók és különféle csomagkezelő integrációk révén
  • Autokonfiguráció. Ha megpróbálja minimalizálni a konfiguráció mennyiségét, akkor egy Spring alkalmazás megköveteli az indulásra való felkészülést, és előnyben részesíti a konvenciót a konfiguráció helyett
  • Gyártásra kész funkciók. Mint például Működtető, jobb naplózás, monitorozás, mutatók vagy különféle PAAS-integrációk
  • Fokozott fejlesztési tapasztalat. Több tesztelő segédprogrammal vagy jobb visszacsatolási hurokkal tavaszi-bakancs-devtools

Ebben a cikkben megvizsgáljuk a Spring Boot 2.0 tervezett változásait és funkcióit. Leírjuk azt is, hogy ezek a változások hogyan segíthetnek bennünket abban, hogy produktívabbak legyünk.

2. Függőségek

2.1. Java alapvonal

A Spring Boot 2.x már nem támogatja a Java 7 és újabb verziókat, mivel a Java 8 a minimális követelmény.

Ez a Java 9-et támogató első verzió is. Az 1.x ágon nem tervezik a Java 9 támogatását. Ez azt jelenti, hogy Ha a legújabb Java kiadást akarja használni, és kihasználja ezt a keretrendszert, akkor a Spring Boot 2.x az egyetlen lehetőség.

2.2. Darabjegyzékben

A Spring Boot minden új kiadásával a Java ökoszisztéma különféle függőségeinek verziói frissülnek. Ezt a Boot tartalmazza darabjegyzékben más néven BOM.

A 2.x-ben ez sem kivétel. Nincs értelme felsorolni őket, de utánanézhetünk spring-boot-dependencies.pom hogy az adott időpontban milyen verziókat használnak.

Néhány kiemelés a minimálisan szükséges verziókkal kapcsolatban:

  • A Tomcat minimálisan támogatott verziója 8.5
  • A hibernált minimális támogatott verzió az 5.2
  • A Gradle minimum támogatott verziója 3.4

2.3. Gradle Plugin

A Gradle beépülő modul jelentős fejlesztéseken és néhány változáson ment keresztül.

Zsíros üvegek létrehozásához bootRepackage Gradle feladata felváltásra kerül bootJar és bootWar üvegeket és háborúkat építeni.

Ha a Gradle beépülő modullal szeretnénk futtatni az alkalmazásokat az 1.x-ben, akkor futtathatnánk gradle bootRun.A 2.x-ben bootRun kiterjeszti Gradle'sét JavaExec. Ez azt jelenti, hogy könnyebben konfigurálhatjuk ugyanazzal a konfigurációval, amelyet általában a klasszikusnál használunk JavaExec feladatok.

Néha azon kapjuk magunkat, hogy szeretnénk kihasználni a Spring Boot BOM előnyeit. De néha nem akarunk teljes Boot alkalmazást létrehozni vagy újracsomagolni.

Ebben a tekintetben érdekes tudni A Spring Boot 2.x alapértelmezés szerint már nem alkalmazza a függőségkezelő plugint.

Ha Spring Boot függőségkezelést szeretnénk, akkor tegyük hozzá:

plugin alkalmazása: 'io.spring.dependency-management'

Ez nagyobb rugalmasságot biztosít számunkra, kevesebb konfigurációval a fent említett forgatókönyvben.

3. Autokonfiguráció

3.1. Biztonság

A 2.x verzióban a biztonsági konfiguráció drámaian leegyszerűsödik. Alapértelmezés szerint minden biztosított, beleértve a statikus erőforrásokat és az Actuator végpontokat is.

Amint a felhasználó kifejezetten konfigurálja a biztonságot, a tavaszi rendszerindítás alapértelmezett beállításai nem érinti azokat. A felhasználó ezután egyetlen helyen konfigurálhatja az összes hozzáférési szabályt.

Ez megakadályozza, hogy küzdjünk WebSecurityConfigurerAdapter rendelési kérdések. Ezek a problémák általában akkor lépnek fel, amikor az Actuator és az App biztonsági szabályokat egyéni módon konfigurálják.

Vessen egy pillantást egy egyszerű biztonsági kódrészletre, amely vegyíti az aktuátor és az alkalmazás szabályait:

http. (PathRequest.toStaticResources (). AtCommonLocations ()) .permitAll () // Statikus erőforrásbiztonság .antMatchers ("/ **") .hasRole ("user") // Alkalmazásbiztonsági szabályok // ...

3.2. Reaktív támogatás

A Spring Boot 2 új indítókat hoz létre a különböző reaktív modulok számára. Néhány példa a WebFlux, valamint a MongoDB, a Cassandra vagy a Redis reaktív megfelelői.

Vannak teszt segédprogramok a WebFlux számára is. Különösen kihasználhatjuk @WebFluxTest. Ez hasonlóan viselkedik, mint az idősebb @WebMvcTest eredetileg a különféle tesztek részeként vezették be szeleteket vissza az 1.4.0-ba.

4. Gyártásra kész funkciók

A Spring Boot néhány hasznos eszközt kínál, amelyek lehetővé teszik számunkra a gyártásra kész alkalmazások létrehozását. Többek között kihasználhatjuk a Spring Boot Actuator előnyeit.

Az Actuator különféle eszközöket tartalmaz a felügyelet, a nyomon követés és az alkalmazás általános önellenőrzésének egyszerűsítésére. Az aktuátorról további részletek találhatók előző cikkünkben.

2 verziójával működtető jelentős fejlesztéseken ment keresztül. Ez az iteráció a testreszabás egyszerűsítésére összpontosít. Ezenkívül más webes technológiákat is támogat, beleértve az új reaktív modult.

4.1. Technológiai támogatás

A Spring Boot 1.x-ben csak a Spring-MVC támogatott az aktuátor végpontjaihoz. A 2.x-ben azonban függetlenné és bedughatóvá vált. A tavaszi csomagtartó most már támogatja a WebFlux, Jersey és Spring-MVC támogatását.

A korábbiakhoz hasonlóan a JMX továbbra is opció marad, és konfigurációval engedélyezhető vagy letiltható.

4.2. Egyéni végpontok létrehozása

Az új működtető infrastruktúra technológia-agnosztikus. Emiatt a fejlesztési modellt a semmiből alakították át.

Az új modell nagyobb rugalmasságot és kifejezőkészséget is jelent.

Nézzük meg, hogyan lehet létrehozni egy Gyümölcsök az aktuátor végpontja:

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

Miután regisztráltunk FruitsEndpoint miénkben ApplicationContext, a választott technológiánk segítségével webes végpontként ki lehet tüntetni. A konfigurációnktól függően a JMX-en keresztül is ki tudtuk tenni.

Végpontunk webes végpontokká történő lefordítása ez a következőket eredményezné:

  • KAP tovább / alkalmazás / gyümölcsök visszatérő gyümölcsök
  • POST tovább / applications / fruits / {a-fruit} az a gyümölcs kezelése, amelyet bele kell foglalni a hasznos teherbe

Sokkal több lehetőség van. Szerezhetnénk részletesebb adatokat. Meghatározhatnánk konkrét megvalósításokat is az alapul szolgáló technológiák szerint (pl. JMX vs. Web). A cikk alkalmazásában egyszerű bevezetésként fogjuk megtartani, anélkül, hogy túlságosan részleteznénk.

4.3. Biztonság az aktuátorban

Tavaszi indításkor az 1.x aktuátor meghatározza saját biztonsági modelljét. Ez a biztonsági modell különbözik attól, amelyet az alkalmazásunk használ.

Ez volt a sok fájdalom gyökere, amikor a felhasználók megpróbálták finomítani a biztonságot.

A 2.x verzióban a biztonsági konfigurációt ugyanazzal a konfigurációval kell konfigurálni, amelyet az alkalmazás többi része használ.

Alapértelmezés szerint a legtöbb működtető végpont le van tiltva. Ez független attól, hogy a Spring Security az osztályterületen van-e vagy sem. Túl állapot és info, az összes többi végpontot engedélyeznie kell a felhasználónak.

4.4. Egyéb fontos változások

  • A legtöbb konfigurációs tulajdonság jelenleg alatt van menedzsment.xxx például.: management.endpoints.jmx
  • Néhány végpont új formátumú. például.: env, repülési út vagy liquibase
  • Az előre definiált végpont útvonalak már nem konfigurálhatók

5. Fokozott fejlesztési tapasztalat

5.1. Jobb visszajelzés

Bemutatták a tavaszi csomagtartót devtools az 1.3.

Gondoskodik a tipikus fejlesztési kérdések elsimításáról. Például a megtekintési technológiák gyorsítótárazása. Automatikus újraindítást és a böngésző élő újratöltését is elvégzi. Ez lehetővé teszi számunkra az alkalmazások távoli hibakeresését is.

A 2.x-ben, amikor az alkalmazás újraindul devtools a „delta” jelentést kinyomtatják. Ez a jelentés rámutat arra, hogy mi változott és milyen hatása lehet alkalmazásunkra.

Tegyük fel, hogy definiálunk egy JDBC adatforrást, felülírva a Spring Boot által konfiguráltat.

Devtools azt jelzi, hogy az automatikus konfiguráció már nem jön létre. Rámutat az okra, a hátrányos meccsre is @ConditionalOnMissingBean típushoz javax.sql.DataSource. Devtools az újraindítás után kinyomtatja ezt a jelentést.

5.2. Megtörő változások

A JDK 9 problémák miatt a devtools megszünteti a HTTP-n keresztüli távoli hibakeresés támogatását.

6. Összefoglalás

Ebben a cikkben bemutattuk a Spring Boot 2 néhány változását.

Megbeszéltük a függőségeket és azt, hogy miként válik a Java 8 a minimálisan támogatott verzióvá.

Ezután az autokonfigurációról beszéltünk. Többek között a biztonságra összpontosítottunk. Beszéltünk a működtetőről és a sok fejlesztésről is.

Végül néhány apróbb trükkről beszéltünk, amelyek a rendelkezésre álló fejlesztési eszközökben történtek.


$config[zx-auto] not found$config[zx-overlay] not found