streamalism.org

1. Bemutatkozás

Ebben az oktatóanyagban megvizsgáljuk az Apache Log4j 2 programozott konfigurálásának különböző módjait.

2. Kezdeti beállítás

A Log4j 2 használatának megkezdéséhez csupán a log4j-core és a log4j-slf4j-impl függőségeket kell felvennünk a pom.xml:

 org.apache.logging.log4j log4j-core 2.11.0 org.apache.logging.log4j log4j-slf4j-impl 2.11.0 

3. ConfigurationBuilder

Miután konfiguráltuk Maven-t, létre kell hoznunk a ConfigurationBuilder, amely az az osztály, amely lehetővé teszi számunkra a konfigurálást függelékek, szűrők, elrendezések, és fakitermelők.

A Log4j 2 számos módot kínál a ConfigurationBuilder.

Kezdjük a legközvetlenebb módon:

ConfigurationBuilder builder = ConfigurationBuilderFactory.newConfigurationBuilder ();

Az összetevők konfigurálásának megkezdéséhez ConfigurationBuilder megfelelővel van felszerelve új módszer, mint newAppender vagy newLayout, minden alkatrészre.

Néhány alkatrésznek különböző altípusai vannak, például FileAppender vagy ConsoleAppender, és ezekre az API-ban hivatkoznak bővítmények.

3.1. A Függelék konfigurálása

Mondjuk el a építész hová küldje el az egyes naplósorokat egy appender:

AppenderComponentBuilder konzol = builder.newAppender ("stdout", "Console"); builder.add (konzol); AppenderComponentBuilder fájl = builder.newAppender ("napló", "Fájl"); file.addAttribute ("fájlnév", "cél / naplózás.log"); builder.add (fájl);

Míg a legtöbb új a módszerek ezt nem támogatják, newAppender (név, bővítmény) lehetővé teszi számunkra, hogy nevet adjunk a pályázónak, ami később fontosnak bizonyul. Ezeket a hozzátartozókat hívtuk stdout és napló, bár bármit megnevezhetnénk nekik.

Azt is elmondtuk a építész melyik függelék csatlakoztat (vagy egyszerűbben: melyik függeléket kell használni). Konzol és File olvassa el a Log4j 2 függelékeit a szabványos és a fájlrendszerhez való íráshoz.

Bár a Log4j 2 számos függeléket támogat, konfigurálása a Java használatával kissé bonyolult lehet, mivel AppenderComponentBuilder egy általános osztály az összes appender típushoz.

Ez olyan módszerekkel rendelkezik, mint addAttribute és addComponent ahelyett setFileName és addTriggeringPolicy:

AppenderComponentBuilder rollingFile = builder.newAppender ("gördülő", "RollingFile"); rollingFile.addAttribute ("fájlnév", "gördülő.log"); rollingFile.addAttribute ("filePattern", "rolling-% d {MM-dd-yy} .log.gz"); builder.add (rollingFile); 

És végül, ne felejtsd el felhívni építő.add hogy hozzáfűzze a fő konfigurációhoz!

3.2. A szűrők konfigurálása

Hozzáadhatunk szűrőket minden függelékünkhöz, amelyek minden naplósoron eldöntik, hogy hozzá kell-e fűzni.

Használjuk a MarkerFilter plugin a konzolos alkalmazásunkon:

FilterComponentBuilder flow = builder.newFilter ("MarkerFilter", Filter.Result.ACCEPT, Filter.Result.DENY); flow.addAttribute ("marker", "FLOW"); konzol.add (flow);

Vegye figyelembe, hogy ez új A módszer nem engedi megnevezni a szűrőt, de arra kéri, hogy jelezzük, mit kell tennünk, ha a szűrő elhalad vagy nem sikerül.

Ebben az esetben egyszerűek voltunk, kijelentve, hogy ha a MarkerFilter akkor passzol ELFOGAD a logline. Másképp, TAGADNI azt.

Ebben az esetben vegye figyelembe, hogy ezt nem csatoljuk a építész hanem ehelyett a mellékletekhez, hogy ezt a szűrőt szeretnénk használni.

3.3. Elrendezések konfigurálása

Ezután határozzuk meg az egyes naplósorok elrendezését. Ebben az esetben a PatternLayout csatlakoztat:

LayoutComponentBuilder standard = builder.newLayout ("PatternLayout"); standard.addAttribute ("minta", "% d [% t]% -5szint:% msg% n% dobható"); konzol.add (standard); file.add (standard); gördülő.add (standard);

Ismét hozzáadtuk ezeket közvetlenül a megfelelő függelékekhez a építész közvetlenül.

3.4. A Root Logger konfigurálása

Most, hogy tudjuk, hová kerülnek a naplók, be akarjuk állítani, hogy mely naplók kerüljenek az egyes célállomásokhoz.

A gyökérnaplózó a legmagasabb naplózó, hasonló Tárgy Java-ban. Alapértelmezés szerint ezt a naplózót használják, hacsak nem írják felül.

Tehát használjunk gyökérnaplózót az alapértelmezett naplózási szint beállításához HIBA és a mi alapértelmezett melléklete stdout appender felülről:

RootLoggerComponentBuilder rootLogger = builder.newRootLogger (Level.ERROR); rootLogger.add (builder.newAppenderRef ("stdout")); builder.add (rootLogger);

Ha a naplózónkat egy adott alkalmazásra mutatjuk, nem adunk neki példát az építtetőről. Helyette, arra hivatkozunk név hogy korábban adtuk.

3.5. További naplók konfigurálása

A gyermeknaplózók felhasználhatók konkrét csomagok vagy naplózónevek megcélozására.

Adjunk hozzá egy naplót a com csomagot az alkalmazásunkban, beállítva a naplózási szintet HIBÁK és hogy azok menjenek a miénkbe napló appender:

LoggerComponentBuilder logger = builder.newLogger ("com", Level.DEBUG); logger.add (builder.newAppenderRef ("log")); logger.addAttribute ("additivitás", hamis); builder.add (naplózó);

Vegye figyelembe, hogy beállíthatjuk additivitás naplózóinkkal, ami jelzi, hogy ennek a naplózónak meg kell-e örökölnie az őseitől az olyan tulajdonságokat, mint a naplózási szint és a függelék típusok.

3.6. Más alkatrészek konfigurálása

Nem minden alkatrész rendelkezik külön dedikálással új módszer be ConfigurationBuilder.

Tehát ebben az esetben hívunk newComponent.

Például azért, mert nincs a TriggeringPolicyComponentBuilder, használnunk kell newComponent valami olyasmi, mint a fájlfüggelékek görgetésére vonatkozó kiváltó irányelvünk megadása:

ComponentBuilder triggeringPolicies = builder.newComponent ("házirendek") .addComponent (builder.newComponent ("CronTriggeringPolicy") .addAttribute ("ütemezés", "0 0 0 * *?")) .AddComponent (builder.negCompon .addAttribute ("méret", "100M"); gördülő.addComponent (triggeringPolicies);

3.7. Az XML egyenértékű

ConfigurationBuilder praktikus módszerrel van felszerelve az egyenértékű XML kinyomtatásához:

builder.writeXmlConfiguration (System.out);

A fenti sor futtatása kinyomtatja:

Ez jól jön, ha ellenőrizni akarjuk a konfigurációnkat, vagy ha meg akarjuk tartani a konfigurációnkat, mondjuk a fájlrendszerben.

3.8. Összedobva az egészet

Most, hogy teljesen konfiguráltuk, mondjuk a Log4j 2-nek, hogy használja a konfigurációnkat:

Configurator.initialize (builder.build ());

Miután erre hivatkozunk, a jövőben a Log4j 2-re irányuló hívások a konfigurációnkat használják.

Ne feledje, hogy ez azt jelenti, hogy meg kell hívnunk Configurator.inicialize mielőtt felhívnánk LogManager.getLogger.

4. ConfigurationFactory

Most, hogy láttunk egy módot a ConfigurationBuilder, nézzünk még egyet:

public class CustomConfigFactory kiterjeszti a ConfigurationFactory {public Configuration createConfiguration (LoggerContext kontextus, ConfigurationSource src) {ConfigurationBuilder builder = super .newConfigurationBuilder (); // ... a függelékek, szűrők stb. konfigurálása return builder.build (); } public String [] getSupportedTypes () {return new String [] {"*"}; }}

Ebben az esetben a használat helyett ConfigurationBuilderFactory, alosztályba soroltuk ConfigurationFactory, egy absztrakt osztály, amelynek célja a Konfiguráció.

Aztán ahelyett, hogy telefonálna Configurator.inicialize csakúgy, mint az első alkalommal, egyszerűen tájékoztatnunk kell a Log4j 2-t az új konfigurációs gyárunkról.

Ennek három módja van:

• Statikus inicializálás
• Futásidejű tulajdonság, ill
• A @Csatlakoztat annotáció

4.1. Használja a Statikus inicializálást

A Log4j 2 támogatja a hívást setConfigurationFactory a statikus inicializálás során:

statikus {ConfigurationFactory custom = new CustomConfigFactory (); ConfigurationFactory.setConfigurationFactory (egyedi); }

Ennek a megközelítésnek ugyanolyan korlátai vannak, mint a legutóbb látott megközelítésnek, vagyis meg kell hívnunk hívás előtt LogManager.getLogger.

4.2. Használjon futásidejű tulajdonságot

Ha hozzáférünk a Java indítási parancshoz, akkor a Log4j 2 támogatja a ConfigurationFactory a-n keresztül használni -D paraméter:

-Dlog4j2.configurationFactory = com.baeldung.log4j2.CustomConfigFactory

A megközelítés legfőbb előnye, hogy nem kell aggódnunk az inicializálási sorrend miatt, mint az első két megközelítésnél.

4.3. Használja a @Csatlakoztat Megjegyzés

És végül olyan körülmények között, amikor nem akarunk a Java indítási paranccsal babrálni a hozzáadásával -D, egyszerűen megjegyezhetjük CustomConfigurationFactory a Log4j 2-vel @Csatlakoztat kommentár:

@Plugin (név = "CustomConfigurationFactory", kategória = ConfigurationFactory.CATEGORY) @Order (50) public class A CustomConfigFactory kiterjeszti a ConfigurationFactory {// ... a megvalósítás többi részét}

A Log4j 2 megvizsgálja az osztályútvonalat azon osztályok számára, amelyeknek van @Csatlakoztat megjegyzés, és, megtalálja ezt az osztályt a ConfigurationFactory kategóriában fogja használni.

4.4. Kombinálás statikus konfigurációval

További előnye az a használatának ConfigurationFactory kiterjesztés az, hogy az egyedi konfigurációkat könnyen kombinálhatjuk más konfigurációs forrásokkal, például az XML-lel:

public Configuration createConfiguration (LoggerContext context, ConfigurationSource src) {return new WithXmlConfiguration (context, src); } 

A forrás A paraméter a statikus XML vagy JSON konfigurációs fájlt jelenti, amelyet a Log4j 2 talál, ha van ilyen.

Foghatjuk azt a konfigurációs fájlt, és elküldhetjük a XmlConfiguration ahová a szükséges átfogó konfigurációt elhelyezhetjük:

a WithXmlConfiguration nyilvános osztály kiterjeszti az XmlConfiguration beállítást {@Orride protected void doConfigure () {super.doConfigure (); // xml dokumentum elemzése // ... adja hozzá az egyéni konfigurációt}}

5. Következtetés

Ebben a cikkben megvizsgáltuk az új használatát ConfigurationBuilder A Log4j 2-ben elérhető API.

Megnéztük a testreszabást is ConfigurationFactory kombinálva valamivel ConfigurationBuilder fejlettebb használati esetekre.

Ne felejtsd el megnézni a teljes példáimat a GitHubon.