streamalism.org

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.