Tavaszi indító alkalmazás futtatása Maven vs Executable War / Jar játékkal

1. Bemutatkozás

Ebben az oktatóanyagban megvizsgáljuk a Spring Boot webalkalmazás elindítása közötti különbségeket a mvn spring-boot: fut parancsot, és futtatni, miután egy jar / war csomagba fordították a java -jar parancs.

Tegyük fel, hogy itt már ismeri a tavaszi csomagtartó konfigurációját újracsomagolás cél. A témával kapcsolatos további részletekért olvassa el a Fat Jar App létrehozása tavaszi indítással című cikket.

2. A tavaszi bakancs Maven beépülő modul

Spring Boot alkalmazás írásakor a Spring Boot Maven plugin az ajánlott eszköz kódunk összeállításához, teszteléséhez és csomagolásához.

Ez a bővítmény számos kényelmes funkcióval rendelkezik, például:

  • megoldja a számunkra megfelelő függőségi verziókat
  • minden függőségünket (beleértve szükség esetén a beágyazott alkalmazásszervereket is) egyetlen, futható kövér edénybe / háborúba csomagolja, és:
    • kezelje nekünk az classpath konfigurációt, így annyi ideig átugorhatjuk -cp lehetőség a mi java -jar parancs
    • hajtson végre egy szokást ClassLoader hogy megtalálja és betöltse az összes külső jar könyvtárat, amelyek most be vannak ágyazva a csomagba
    • automatikusan megtalálja a fő() metódus és konfigurálja a jegyzékben, így nem kell megadnunk a fő osztályt a java -jar parancs

3. A kód futtatása Maven-nel robbanva

Amikor egy webalkalmazáson dolgozunk, kihasználhatjuk a Spring Boot Maven plugin: a webalkalmazásunk beágyazott alkalmazásszerveren történő automatikus telepítésének lehetősége.

Csak egy függőségre van szükségünk, hogy a plugin tudassa, hogy a Tomcat programot akarjuk használni a kódunk futtatásához:

 org.springframework.boot spring-boot-starter-web 

Most, amikor a mvn spring-boot: fut parancsot a projekt gyökérmappájában, a plugin beolvassa a pom konfigurációját és megérti, hogy szükségünk van egy webalkalmazás-tárolóra.

A. Végrehajtása mvn spring-boot: fut parancs elindítja az Apache Tomcat letöltését és inicializálja a Tomcat indítását.

Próbáljuk ki:

$ mvn spring-boot: futtatás ... ... [INFO] ---------------------------------- ------ [INFO] Tavaszi csomagtartó építése 0.0.1-SNAPSHOT [INFO] --------------------------- ----- [háború] --------------------------------- [INFO] [INFO] >>> spring-boot-maven-plugin: 2.1.3. KÖZLEMÉNY: futtatás (alapértelmezett-cli)> test-compile @ spring-boot-ops >>> Letöltés központi részről: //repo.maven.apache.org/maven2/org /apache/tomcat/embed/tomcat-embed-core/9.0.16/tomcat-embed-core-9.0.16.pom Letöltött a központból: //repo.maven.apache.org/maven2/org/apache/tomcat/ embed / tomcat-embed-core / 9.0.16 / tomcat-embed-core-9.0.16.pom (1,8 kB 2,8 kB / s) ... plugin: 2.1.3.KÖZLEMÉNY: futtatás (alapértelmezett-cli) @ spring-boot-ops --- ... ... 11: 33: 36.648 [main] INFO oacatalina.core.StandardService - Szolgáltatás indítása [Tomcat] 11: 33: 36.649 [main] INFO oacatalina.core.StandardEngine - Servlet motor indítása: [Apache Tomcat / 9.0.16] ... ... 11: 33: 36.952 [main] INFO oaccC [Tomcat]. [Localhost ]. [/] - A tavasz inicializálása em ágyas WebApplicationContext ... ... 11: 33: 48.223 [main] INFO oacoyote.http11.Http11NioProtocol - Starting ProtocolHandler ["http-nio-8080"] 11: 33: 48.289 [main] INFO osbwetomcat.TomcatWebServer - Tomcat a következő porton (ok) kezdődött: 8080 (http) kontextusúttal "" 11: 33: 48.292 [main] INFO org.baeldung.boot.Application - Az alkalmazás 22,454 másodperc alatt elindult (a JVM futása 37,692 alatt)

Amikor a napló az „Indított alkalmazás” sort tartalmazza, webalkalmazásunk készen áll a lekérdezésre a böngészőn keresztül a következő címen: // localhost: 8080 /

4. A kód futtatása önálló csomagolt alkalmazásként

Miután túljutottunk a fejlesztési szakaszon, és előrelépni akarunk az alkalmazásunk termelésbe állítása felé, csomagolnunk kell az alkalmazásunkat.

Sajnos, ha a befőttes üveg csomag, az alap Maven csomag A cél nem tartalmazza a külső függőségeket.

Ez azt jelenti, hogy csak egy nagyobb projektben használhatjuk könyvtárként.

Ennek a korlátozásnak a kijátszása érdekébenki kell használnunk a Maven Spring Boot plugint újracsomagolás cél, hogy önálló alkalmazásként futtassuk a jar / háborút.

4.1. Konfiguráció

Általában csak a build plugint kell konfigurálnunk:

  ... org.springframework.boot spring-boot-maven-plugin ... 

De a példaprojektünk egynél több főosztályt tartalmaz, ezért meg kell mondanunk a Java-nak, hogy melyik osztályt futtassa, a plugin konfigurálásával:

 org.springframework.boot spring-boot-maven-plugin com.baeldung.webjar.WebjarsdemoApplication 

vagy a kezdő osztály ingatlan:

 com.baeldung.webjar.WebjarsdemoApplication 

4.2. Az alkalmazás futtatása

Most két egyszerű paranccsal futtathatjuk a háborús példánkat:

$ mvn tiszta csomag spring-boot: újracsomagol $ java -jar target / spring-boot-ops.war

A jar fájl futtatásáról további részletek a JAR alkalmazás futtatása parancssori argumentumokkal című cikkünkben találhatók.

4.3. A háborús aktában

Annak érdekében, hogy jobban megértsük, hogyan képes a fent említett parancs egy teljes kiszolgálóalkalmazást futtatni, bepillanthatunk a mi tavaszi bakancs-ops.war.

Ha kibontjuk és belenézünk, a szokásos gyanúsítottakat találjuk:

  • META-INF, az automatikusan létrehozott MANIFEST.MF
  • WEB-INF / osztályok, amely az összeállított osztályainkat tartalmazza
  • WEB-INF / lib, amely a háborús függőségeinket és a beágyazott Tomcat jar fájlokat tartalmazza

Ez még nem minden, mivel a zsírcsomag-konfigurációnknak vannak mappái:

  • WEB-INF / lib-biztosított, amely tartalmazza a beágyazott futtatásához szükséges, de a telepítéshez nem szükséges külső könyvtárakat
  • org / springframework / boot / loader, amely a Spring Boot egyéni osztály betöltőt tartalmazza - ez a könyvtár felelős a külső függőségeink betöltéséért és futás közbeni elérhetővé tételéért

4.4. A háborús kiáltvány belsejében

Mint korábban említettük, a Maven Spring Boot plugin megtalálja a fő osztályt, és létrehozza a Jáva parancs.

A kapott MANIFEST.MF van néhány további sora:

Start-osztály: com.baeldung.webjar.WebjarsdemoApplication Főosztály: org.springframework.boot.loader.WarLauncher

Különösen megfigyelhetjük, hogy az utolsó megadja a Spring Boot osztályú betöltő indítót.

4.5. Jar fájlban

Az alapértelmezett csomagolási stratégia miatt a háborús csomagolás a forgatókönyv nem sokban különbözik attól, hogy a Tavaszi Boot Maven beépülő modul vagy nem.

A plugin előnyeinek jobb értékelése érdekében megpróbálhatjuk megváltoztatni a pomot csomagolás konfiguráció befőttes üveg és futni mvn tiszta csomag újra.

Most megfigyelhetjük, hogy a kövér edényünk kissé eltérően szerveződik, mint az előző háborús fájlunk:

  • Az összes osztály és erőforrás mappánk most található BOOT-INF / osztályok
  • BOOT-INF / lib az összes külső könyvtárat tartalmazza

A plugin nélkül a lib mappa nem létezne, és a BOOT-INF / osztályok a csomag gyökerében található.

4.6. A Korsó Kiáltvány belsejében

Továbbá a NYILVÁNVALÓ.Az MF megváltozott, a következő sorokkal:

Spring-Boot-osztályok: BOOT-INF / class / Spring-Boot-Lib: BOOT-INF / lib / Spring-Boot-Version: 2.1.3. KÖZLEMÉNY Főosztály: org.springframework.boot.loader.JarLauncher

Spring-Boot-osztályok és Tavasz-Csizma-Lib különösen érdekesek, mivel elmondják nekünk, hogy az osztály betöltő hol talál osztályokat és külső könyvtárakat.

5. Hogyan válasszuk

Az eszközök elemzésekor feltétlenül figyelembe kell venni az ezen eszközök létrehozásának célját. Szeretnénk megkönnyíteni a fejlesztést, vagy biztosítani a zökkenőmentes telepítést és hordozhatóságot? Vessünk egy pillantást a választás által leginkább érintett fázisokra.

5.1. Fejlődés

Fejlesztőként gyakran időnk nagy részét kódolással töltjük, anélkül, hogy sok időt kellene töltenünk a környezetünk felállításával a kód helyi futtatására. Egyszerű alkalmazásokban ez általában nem okoz gondot. De összetettebb projektek esetén szükség lehet környezeti változók beállítására, a szerverek indítására és az adatbázisok feltöltésére.

A megfelelő környezet konfigurálása minden alkalommal, amikor az alkalmazást futtatni szeretnénk, nagyon nem praktikus, főleg, ha egynél több szolgáltatást kell futtatni.

Ebben segít nekünk a kód futtatása Maven-lel. A teljes kódbázist már helyben megvizsgáltuk, így kihasználhatjuk a pom konfigurációs és erőforrás fájlokat. Beállíthatunk környezeti változókat, létrehozhatunk egy memóriában lévő adatbázist, sőt letölthetjük a megfelelő szerver verziót és egy paranccsal telepíthetjük az alkalmazást.

Még egy több modulos kódbázisban is, ahol mindegyik modulhoz különféle változókra és szerver verziókra van szükség, könnyen futtathatjuk a megfelelő környezetet a Maven profilokon keresztül.

5.2. Termelés

Minél jobban haladunk a termelés felé, annál inkább elmozdul a beszélgetés a stabilitás és a biztonság felé. Ezért nem alkalmazhatjuk a fejlesztőgépünkhöz használt folyamatot egy élő ügyfelekkel rendelkező szerverre.

A kód futtatása a Mavenen keresztül ebben a szakaszban több okból is rossz gyakorlat:

  • Először is telepítenünk kellene a Mavent
  • Ezután csak azért, mert össze kell állítanunk a kódot, szükségünk van a teljes Java Development Kit-re (JDK)
  • Ezután át kell másolnunk a kódbázist a szerverünkre, az összes saját kódunkat egyszerű szövegben hagyva
  • A mvn a parancsnak az életciklus összes szakaszát végre kell hajtania (forrásokat kell keresni, lefordítani és futtatni)
  • Az előző pontnak köszönhetően a CPU-t és felhőszerver esetén pénzt is pazarolnánk
  • A Maven több Java folyamatot szül, mindegyik memóriát használ (alapértelmezés szerint mindegyik ugyanazt a memóriamennyiséget használja, mint a szülő folyamat)
  • Végül, ha több szervert telepítünk, akkor a fentiek mindegyike megismétlődik

Ez csak néhány ok, amiért az alkalmazás csomagként történő szállítása praktikusabb a gyártáshoz.

6. Következtetés

Ebben az oktatóanyagban feltártuk a különbségeket a kód futtatása között a Mavenen és a java -jar parancs. Gyors áttekintést is készítettünk néhány gyakorlati eset forgatókönyvéről.

A cikkben használt forráskód elérhető a GitHubon.