java fakitermelés

előző ◈ a következő

belépés

Azt hiszem, ez nem titok, hogy az ilyen favágók és mire van szükségük. Fennállása alatt a java jött létre sok fakitermelés keretek között. A legjelentősebbek között vannak:

  • Július - java.util.logging
  • log4j
  • JCL - Jakarta commons fakitermelés
  • Logback
  • SLF4J - egyszerű naplózás homlokzat java

System.err.println

Java.util.logging

Ez a keret tartalmazza a szabványos és mellékelve van a JDK, így semmi extra, hogy töltse le és akkor nem kell csatlakoztatni. Július a következő naplózási szintet emelkedő: LEGFINOMABB FiNomaBB, finom, CONFIG, INFO, FIGYELEM, SÚLYOS, valamint az összes és az OFF, és tartalmaz bontása minden szinten, ill.
Logger létre hívja az egyik statikus módszerek java.util.logging.Logger osztály:

Logger módszereket is igénybe vehet, mint argumentum, üzenet sablonok, kivételek, forrásokat lokalizált feliratokat üzeneteket, valamint a Java 8, kereskedők húr hozzászólás:

Feltéve, hogy a két csoport módszer: a név, amely megfelel a fakitermelés és módszerek jelentkezzen, loggp, logrb, fogadó naplózási szint paraméterként a fajta szint. Az első csoportba tartoznak kétféle módszer: olyan üzenet fogadása zsineget vagy húrok szállító Üzenetek:

A második csoport a módszerek a következő eltérések:

Most térjünk át a konfigurációs keretet. Alapértelmezésben július megjeleníti az üzeneteket a konzolon, de beállítható a tulajdonságok fájlt. Annak megadásához, hogyan kell megjeleníteni üzenetet, meg kell határoznia, rakodók a logger kell használni. Vannak következő osztályai rakodók: FileHandler, ConsoleHandler, StreamHandler, SocketHandler, MemoryHandler. Július különlegessége az, hogy a felvezető beállítások általában az egész osztály, nem egy konkrét esetben, hogy képes generálni jó néhány problémát, például, ha szüksége van egy másik üzenet naplózó kimenetet különböző fájlokat, vagy más formázást. Tekintsünk egy egyszerű példa konfigurációs fájl:

Annak érdekében, hogy e konfiguráció július kell átadni paraméterként -Djava.util.logging.config.file = <путь до файла>, vagy ha az alkalmazás elkezdi végrehajtani a kód:

Ez a keret jelenleg már a második verzió, ami sajnos nem kompatibilis az első. Mivel az első változat log4j ott sokáig, és tekintettel arra, hogy nagy népszerűségnek, van jó néhány cikket az interneten, ma nézzük a második. Ahhoz, hogy használni log4j2 meg kell csatlakoztatni a könyvtárak log4j-api-2.x és log4j-core-2.x. Log4j több elkülönülő július elnevezési naplózási szintek: TRACE, DEBUG, INFO, WARN, HIBA, FATAL, valamint ALL OFF, és lehetővé teszi, és letiltja minden szinten, ill.
Logger létre hívja a statikus módszer org.apache.logging.log4j.Logger osztály:

Az adatgyűjtő vehet már megszokott String, Object és Eldobható két új típusú - MapMessage és Marker:

A klasszikus stílusban favágók módszerek két csoportba sorolhatjuk, amely egybeesik a név naplózási szint és jelentkezzen technikák, figyelembe naplózási szint paraméterként. Az első, hogy a következő formában:

jelentkezzen be log4j2 módszerek a következők:

Ha nem adja meg a konfiguráció, az indítási ad log4j2 dühös üzenetet, hogy a konfiguráció nincs beállítva, és kiírja az üzenetet a konzol szinten nem kevesebb, mint hiba. Configuration log4j2 adott több lehetőség: xml, JSON, YAML. Érdemes megjegyezni, hogy a második verzió nem támogatja a konfiguráció az ingatlan fájlt. A konfigurációs fájl automatikusan megkeresi classpath, log4j2 kell egy nevet, és elhelyezkedhet az alapértelmezett csomagot.
A konfigurációs áll leírását log4j2 favágók, appenderov és szűrők. A részletesebb vizsgálat, lásd a dokumentációt, de most csak megemlíteni néhány kulcsfontosságú pontokat. Először is, vannak különböző nyalánkság formájában szűrők, beleértve a markerek:

  • BurstFilter
  • CompositeFilter
  • DynamicThresholdFilter
  • MapFilter
  • MarkerFilter
  • RegexFilter
  • StructuredDataFilter
  • ThreadContextMapFilter
  • ThresholdFilter
  • TimeFilter

Másodszor, van egy széles körű osztályok appenderov, beleértve az aszinkron és a appendery appendery csomagolópapír egy csoport más appenderov:

  • AsyncAppender
  • ConsoleAppender
  • FailoverAppender
  • FileAppender
  • FlumeAppender
  • JDBCAppender
  • JMSAppender
  • JPAAppender
  • MemoryMappedFileAppender
  • NoSQLAppender
  • OutputStreamAppender
  • RandomAccessFileAppender
  • RewriteAppender
  • RollingFileAppender
  • RollingRandomAccessFileAppender
  • RoutingAppender
  • SMTPAppender
  • SocketAppender
  • SyslogAppender

Azt is meg kell jegyezni, hogy log4j hozhat létre sok különböző appenderov az azonos osztályú, mint például a több fájl appenderov akik írnak a különböző fájlokat.
Tekintsük a példát olyan összeállítás, amelyben a két bejelentett logger (és a gyökér a mi osztály), amelyek közül az első írja log.log fájlt, és a második írja log2.log szűrés segítségével a marker:

Commons-naplózás

Elég egy régi projekt, amely egy wrapper át július és log4j, nem vont le semmilyen további szolgáltatásokat. naplózási szintek JCL egybeesnek log4j, és abban az esetben való kölcsönhatás július követően lép fel, összehasonlítás:

Ahhoz, hogy használni JCL csatlakozni commons-naplózó-1.x.jar. Hozzon létre egy adatgyűjtő hívja a gyári módszer:

JCL módszerek nagyon egyszerűek, ugyanaz, mint a neve naplózási szintek csak akkor tárgyak és a kirekesztés két változat:

JCL konfiguráció tartalmaz különálló egységek log4j, július és önmegvalósítás. Ha nem adja meg a konfiguráció használ saját végrehajtását, az úgynevezett SimpleLog, amely üzeneteket jelenít meg a konzolon. Tekintsük a következő konfigurációs fájl:

JCL adja meg a konfigurációs fájlt az alábbiak szerint:

Ez a keret csak együtt egy wrapper SLF4J, amely azt fogja vizsgálni később. A kezdéshez meg kell logback-core-1.x.jar és logback-classic-1.x.x.jar. és slf4j-api-1.x.x.jar.
Kölcsönhatás a naplózó, akkor végre az API-nak a wrapper SLF4J. A naplózási szintek egybeesnek log4j. Létrehozása logger ebben az esetben a következő:

API lehetővé teszi, hogy megjelenítse a húr üzenetet, húr, üzenetsablonokat, kivételeket, és felhasználása markerek:

Módszer neve egybeesik naplózási szintek és a következő formában:

Most tekintsük a spontán funkcionális logback. Konfigurációja osztályútvonal keresi a következő sorrendben:

  1. Ő próbál találni logback.groovy
  2. Ellenkező esetben, megpróbálja megtalálni logback-test.xml
  3. Ellenkező esetben, megpróbálja megtalálni logback.xml
  4. Ellenkező esetben használja alap konfiguráció - megjelenít egy üzenetet a konzolon

A fő elemei a konfiguráció a favágók, appendery, layauty, és szűrők.
Vannak az alábbi szűrők:

  • rendszeres szűrők
  • LevelFilter
  • ThresholdFilter
  • EvaluatorFilter
  • Matchers
  • TurboFilters
  • CountingFilter

Van appendery következő:

  • OutputStreamAppender
  • ConsoleAppender
  • FileAppender
  • RollingFileAppender
  • SocketAppender és SSLSocketAppender
  • ServerSocketAppender és SSLServerSocketAppender
  • SMTPAppender
  • SyslogAppender
  • SiftingAppender
  • AsyncAppender

Az a tény, hogy az ilyen elrendezések és jeladók a logback kérjük, olvassa el részletesen a dokumentációban, és most már csak egy egyszerű példát logback.xml file:

Amint azt korábban említettük SLF4J pakolások felett logback, valamint a július, log4j, vagy a JCL, valamint bármely adatgyűjtő, amely megvalósítja a felület. Ahhoz, hogy működjön együtt a könyvtár szükséges SLF4J slf4j-api-1.x.x.jar és végrehajtása egyik favágók vagy a csatlakozó. Főszabályként a végrehajtása során adatgyűjtők (kivéve logback) mellékelt SLF4J és nevek hasonlósága slf4j-JCL-1.x.jar, slf4j-log4j12-1.x.jar, slf4j-NOP-1.x.jar és így tovább. n. Ha a osztályútvonal megtalálható végrehajtása logger (vagy dugó NOP) SLF4J rugnetsya dühös, és megtagadják a munkát. A konfiguráció lehet keresni, illetve attól függően, hogy a helyzet a classpath végrehajtása.
API SLF4J vettük figyelembe az előző pontban, ezért nézzük meg egy másik lehetőséget wrapper. Egy ideális világban, meg kell jeleníteni üzenetek révén a burkolat felület, és akkor minden rendben lesz, de az igazi kegyetlen világ azt mondja, hogy mindannyian, hogy kölcsönhatásba lépnek a harmadik féltől származó könyvtárak, vagy kód, használjon más favágók és akik tudják, nem ismerik SLF4J . Ez nem alkalmazkodnak minden adatgyűjtő és hagyja, hogy a dolgok hogy az üzenetek révén egy végrehajtási SLF4J interfész, akkor áthidaló. A kínálat a wrapper könyvtár tartalmazott JCL-over-slf4j.jar, log4j-over-slf4j.jar és július-to-slf4j.jar, amely felülírja a magatartását a adatgyűjtők és átirányítja az üzeneteket a wrapper.
Mi lesz tisztább a fenti, vegyünk egy példát. Tegyük fel, hogy a következő adatgyűjtők:

Azt akarja, hogy az üzenetet a július jegyeztek fel egyetlen fájlt log4j a másikra, és slf4j jelenik meg a konzolon. Mi kell használni logback konfigurációja ez csúnyaság jelenik meg a megvalósítása a burkolat az alábbiak szerint:

Annak érdekében, hogy hidat, amely megszerezte kell futtatni a kódot:

Szeretnék többet

következtetés

Végezetül azt szeretném mondani, hogy a végső döntés a keret fakitermelés mindig rajtad, de ezt el kell megközelíteni érzékelhetően. A választás kell kötni megelégedésére sok kritériumok, mint például a nagy teljesítményű, felhasználóbarát az API, a rendelkezésre álló eszközök tárolására a naplózott adatok és a sajátosságait a projekt, például, ha a terméket fogják használni más projektekben, nem szükséges, hogy megoldja a felhasználó számára, hogy hogyan logger szükséges használni, és ezen a helyen, hogy előnyben részesíti a burkolat.

Kapcsolódó cikkek

előző ◈ a következő