A tavaszi alkalmazások hibakeresése
1. Bemutatkozás
A hibakeresés az egyik legfontosabb eszköz a szoftveríráshoz.
Ebben az oktatóanyagban áttekintjük a Spring alkalmazások hibakeresésének néhány módját.
Meglátjuk azt is, hogy a Spring Boot, a hagyományos alkalmazáskiszolgálók és az IDE-k hogyan egyszerűsítik ezt.
2. Java Debug Args
Először nézzük meg, mit ad nekünk a Java a dobozból.
Alapértelmezés szerint a JVM nem engedélyezi a hibakeresést. Ennek oka, hogy a hibakeresés további általános költségeket eredményez a JVM-en belül. Biztonsági problémát jelenthet a nyilvánosan hozzáférhető alkalmazások számára is.
Ebből kifolyólag, hibakeresést csak a fejlesztés során szabad végrehajtani és soha nem a termelési rendszereken.
Mielőtt csatolhatnánk egy hibakeresőt, először konfigurálnunk kell a JVM-et a hibakeresés engedélyezéséhez. Ezt úgy tesszük, hogy beállítunk egy parancssori argumentumot a JVM számára:
-agentlib: jdwp = transport = dt_socket, szerver = y, suspend = n, address = 8000
Bontjuk le, mit jelentenek ezek az értékek:
-agentlib: jdwp
Engedélyezze a Java Debug Wire Protocol (JDWP) ügynököt a JVM-en belül. Ez a fő parancssori argumentum, amely lehetővé teszi a hibakeresést.
transport = dt_socket
Használjon hálózati csatlakozót a kapcsolatok hibakereséséhez. További lehetőségek a Unix foglalatok és a megosztott memória.
szerver = y
Figyelje a bejövő hibakereső kapcsolatokat. Ha beállítva n, a folyamat megpróbál csatlakozni egy hibakeresőhöz ahelyett, hogy megvárná a bejövő kapcsolatokat. További argumentumok szükségesek, ha ez értéke n.
felfüggeszt = n
Induláskor ne várjon hibakeresési kapcsolatot. Az alkalmazás normálisan indul és fut, amíg egy hibakeresőt nem csatolnak. Ha beállítva y, a folyamat csak egy hibakereső csatolásakor indul el.
cím = 8000
A hálózati port, amelyen a JVM figyeli a hibakeresési kapcsolatokat.
A fenti értékek szabványosak, és a legtöbb használati esetben és az operációs rendszerekben működni fognak. A JPDA csatlakozási útmutató részletesebben ismerteti az összes lehetséges értéket.
3. Tavaszi indító alkalmazások
A Spring Boot alkalmazásokat többféleképpen lehet elindítani. A legegyszerűbb mód a parancssorból a Jáva parancsot -befőttes üveg választási lehetőség.
A hibakeresés engedélyezéséhez egyszerűen hozzáadjuk a debug argumentumot a -D választási lehetőség:
java -jar myapp.jar -Dagentlib: jdwp = transport = dt_socket, szerver = y, suspend = n, address = 8000
Maven-nel használhatjuk a rendelkezésre bocsátottakat fuss az alkalmazásunk hibakereséssel történő elindításának célja:
mvn spring-boot: futtassa -Dagentlib: jdwp = transport = dt_socket, szerver = y, suspend = n, address = 8000
Hasonlóképpen, Gradle esetén használhatjuk a bootRun feladat. Először frissítenünk kell a épít.gradle fájlt annak biztosítására, hogy Gradle átadja a parancssori argumentumokat a JVM-nek:
bootRun {systemProperties = System.properties}
Most végre tudjuk hajtani a bootRun feladat:
gradle bootRun -Dagentlib: jdwp = szállítás = dt_socket, szerver = y, felfüggesztés = n, cím = 8000
4. Alkalmazásszerverek
Míg a Spring Boot az utóbbi években nagyon népszerűvé vált, a hagyományos alkalmazásszerverek még mindig meglehetősen elterjedtek a modern szoftverarchitektúrákban. Ebben a szakaszban megvizsgáljuk, hogyan lehet engedélyezni a hibakeresést néhány népszerűbb alkalmazáskiszolgálón.
A legtöbb alkalmazáskiszolgáló szkriptet biztosít az alkalmazások indításához és leállításához. A hibakeresés engedélyezése általában csak további argumentumok hozzáadását jelenti ehhez a szkripthez és / vagy további környezeti változók beállítását.
4.1. Kandúr
A Tomcat indító szkriptje meg van nevezve catalina.sh (catalina.bat Windows rendszeren). A Tomcat szerver indításához engedélyezzük a hibakeresést jpda az érvekhez:
catalina.sh jpda kezdet
Az alapértelmezett hibakeresési argumentumok egy hálózati foglalatot használnak a 8000-es porton felfüggeszt = n. Ezek a következő környezeti változók közül egy vagy több beállításával módosíthatók: JPDA_TRANSPORT , JPDA_ADDRESS, és JPDA_SUSPEND.
Beállítással teljes mértékben ellenőrizhetjük a hibakeresési argumentumokat is JPDA_OPTS . Ha ez a változó be van állítva, akkor elsőbbséget élvez a többi JPDA változóval szemben. Így teljes hibakeresési argumentumnak kell lennie a JVM számára.
4.2. Wildfly
A Wildfly indító szkriptje önálló.sh. A Wildfly szerver indításához engedélyezve a hibakeresést hozzáadhatjuk –Debug.
Az alapértelmezett hibakeresési mód hálózati figyelőt használ a 8787 porton a következővel: felfüggeszt = n. Felülírhatjuk a portot, ha a. Után adjuk meg –Debug érv.
A hibakeresési argumentum további ellenőrzéséhez egyszerűen hozzáadhatjuk a teljes hibakeresési argumentumokat a JAVA_OPTS környezeti változó.
4.3. Weblogic
A Weblogic indító szkriptje a startWeblogic.sh. A weblog kiszolgáló elindításához engedélyezve a hibakeresés beállíthatjuk a környezeti változót debugFlag nak nek igaz.
Az alapértelmezett hibakeresési mód hálózati figyelőt használ a 8453 porton a felfüggeszt = n. A. Beállításával felülírhatjuk a portot DEBUG_PORT környezeti változó.
A hibakeresési argumentum további ellenőrzéséhez egyszerűen hozzáadhatjuk a teljes hibakeresési argumentumokat a JAVA_OPTIONS környezeti változó.
A Weblogic legújabb verziói Maven plugint is tartalmaznak a szerverek indításához és leállításához. Ez a bővítmény ugyanazokat a környezeti változókat fogja tiszteletben tartani, mint az indítási szkript.
4.4. Üveghal
A Glassfish indítási szkriptje asadmin. A Glassfish szerver indításához, ahol engedélyezve van a hibakeresés, használnunk kell –Debug:
asadmin start-domain - debug
Az alapértelmezett hibakeresési mód hálózati figyelőt használ a 9009-es porton felfüggeszt = n.
4.5. Móló
A Jetty alkalmazáskiszolgálóhoz nem tartozik indító szkript. Ehelyett a Jetty szerverek elkezdik használni a Jáva parancs.
Így a hibakeresés engedélyezése olyan egyszerű, mint a standard JVM parancssori argumentumok hozzáadása.
5. Hibakeresés IDE-ből
Most, hogy láttuk, hogyan lehet engedélyezni a hibakeresést a különböző alkalmazástípusokban, nézzük meg a hibakereső csatlakoztatását.
Minden modern IDE hibakeresési támogatást kínál. Ez magában foglalja az új folyamat elindításának lehetőségét engedélyezett hibakereséssel, valamint a már futó folyamat hibakeresését.
5.1. IntelliJ
Az IntelliJ első osztályú támogatást kínál a Spring and Spring Boot alkalmazásokhoz. A hibakeresés olyan egyszerű, mint az osztályra való navigálás a fő- módszerrel, kattintson a jobb gombbal a háromszög ikonra, és válassza a Hibakeresés lehetőséget.

Ha egy projekt több Spring Boot alkalmazást tartalmaz, az IntelliJ egy Run Dashboard eszközablakot biztosít. Ez az ablak lehetővé teszi több Spring Boot alkalmazás hibakeresését egyetlen helyről:

A Tomcat vagy más webszervereket használó alkalmazásokhoz egyedi konfigurációt hozhatunk létre a hibakereséshez. Alatt Fuss >Konfigurációk szerkesztése, számos sablon létezik a legnépszerűbb alkalmazáskiszolgálókhoz:

Végül az IntelliJ segítségével nagyon egyszerűen csatlakozhat bármely futó folyamathoz és hibakeresést végezhet. Amíg az alkalmazást a megfelelő hibakeresési argumentumokkal indították el, Az IntelliJ akkor is csatlakozhat hozzá, ha egy másik gépen van.
A Konfigurációk futtatása / hibakeresése képernyőn, a Távoli sablon segítségével konfigurálhatjuk a már futó alkalmazáshoz való csatolást:

Ne feledje, hogy az IntelliJ csak a hosztnevet és a hibakereső portot ismeri. Kényelemként elmondja nekünk a megfelelő JVM parancssori argumentumokat, amelyeket fel kell használni az alkalmazáson, amelyet hibakeresni akarunk.
5.2. Fogyatkozás
A Spring Boot alkalmazás hibakeresésének leggyorsabb módja az Eclipse programban az, ha az egér jobb oldali gombjával kattintson a fő módszerre Package Explorer vagy Vázlat ablakok:

Az Eclipse alapértelmezett telepítése nem támogatja a tavaszi vagy a rugós indítást a dobozból. Az Eclipse piactéren azonban elérhető egy Spring Tools kiegészítő, amely az IntelliJ-hez hasonló tavaszi támogatást nyújt.
Legfőképpen a kiegészítő egy Boot Dashboard-ot biztosít, amely lehetővé teszi számunkra, hogy több Spring Boot alkalmazást egyetlen helyről kezeljünk:

A kiegészítő biztosítja a Tavaszi csizma Futtatás / hibakeresés konfiguráció, amely lehetővé teszi egyetlen Spring Boot alkalmazás hibakeresésének testreszabását. Ez a testreszabott nézet ugyanazon a helyen érhető el, mint a standard Java alkalmazás konfiguráció.
Egy már futó folyamat hibakereséséhez, akár lokálisan, akár távoli gazdagépen, használhatjuk a Távoli Java alkalmazás konfiguráció:

6. Hibakeresés a Dockerrel
A Spring alkalmazás hibakeresése a Docker-tárolóban további konfigurációt igényelhet. Ha a tároló helyben fut, és nem gazda hálózati módot használ, akkor a hibakereső port nem lesz elérhető a tárolón kívül.
A Docker hibakereső portjának többféle módja van.
Tudjuk használni –Kiteszik a ... val dokkoló futás parancs:
docker run - exponáljon 8000 mydockerimage-et
Hozzáadhatjuk a EXPOZÍCIÓ irányelv a Dockerfile:
8000 EXPOZÍCIÓ
Vagy ha a Docker Compose programot használjuk, felvehetjük a YAML-be:
kitenni: - "8000"
7. Következtetés
Ebben a cikkben megtudtuk, hogyan lehet engedélyezni a hibakeresést bármely Java alkalmazás számára.
Egyetlen parancssori argumentum hozzáadásával könnyen hibakereshetünk bármilyen Java alkalmazást.
Azt is láttuk, hogy a Maven és a Gradle, valamint a legnépszerűbb IDE-k mindegyike rendelkezik speciális kiegészítőkkel, amelyek még egyszerűbbé teszik a Spring és Spring Boot alkalmazások hibakeresését.