streamalism.org

1. Introduksjon

I denne opplæringen tar vi en titt på forskjellige måter å konfigurere Apache Log4j 2 programmatisk på.

2. Første oppsett

For å begynne å bruke Log4j 2, trenger vi bare å inkludere avhengighetene log4j-core og log4j-slf4j-impl i pom.xml:

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

3. ConfigurationBuilder

Når vi har konfigurert Maven, må vi lage en ConfigurationBuilder, som er klassen som lar oss konfigurere appenders, filtre, layouter, og loggere.

Log4j 2 gir flere måter å få en ConfigurationBuilder.

La oss starte med den mest direkte måten:

ConfigurationBuilder builder = ConfigurationBuilderFactory.newConfigurationBuilder ();

Og for å begynne å konfigurere komponenter, ConfigurationBuilder er utstyrt med en tilsvarende ny metode, som newAppender eller newLayout, for hver komponent.

Noen komponenter har forskjellige undertyper, som FileAppender eller ConsoleAppender, og disse er referert til i API som plugins.

3.1. Konfigurere appenders

La oss fortelle det bygger hvor du skal sende hver logglinje ved å konfigurere en appender:

AppenderComponentBuilder-konsoll = builder.newAppender ("stdout", "Console"); builder.add (konsoll); AppenderComponentBuilder file = builder.newAppender ("logg", "File"); file.addAttribute ("filnavn", "mål / logging.log"); builder.add (fil);

Mens de fleste ny metoder støtter ikke dette, newAppender (navn, plugin) tillater oss å gi appender et navn, som vil vise seg å være viktig senere. Disse appenders, har vi ringt stdout og Logg, selv om vi kunne ha kalt dem noe.

Vi har også fortalt bygger hvilken appender plugg inn (eller, enklere, hvilken type appender) du skal bruke. Konsoll og Fil se Log4j 2s appenders for å skrive til henholdsvis standard ut og filsystemet.

Selv om Log4j 2 støtter flere appenders, å konfigurere dem ved hjelp av Java kan være litt vanskelig siden AppenderComponentBuilder er en generisk klasse for alle appender-typer.

Dette gjør at den har metoder som addAttribute og addComponent i stedet for setFileName og addTriggeringPolicy:

AppenderComponentBuilder rollingFile = builder.newAppender ("rullende", "RollingFile"); rollingFile.addAttribute ("filnavn", "rullende.logg"); rollingFile.addAttribute ("filePattern", "rolling-% d {MM-dd-yy} .log.gz"); builder.add (rollingFile); 

Og endelig, ikke glem å ringe builder.add for å legge den til hovedkonfigurasjonen!

3.2. Konfigurere filtre

Vi kan legge til filtre til hver av våre appenders, som bestemmer på hver logglinje om den skal legges til eller ikke.

La oss bruke MarkerFilter plugin på konsollappenderen vår:

FilterComponentBuilder flow = builder.newFilter ("MarkerFilter", Filter.Result.ACCEPT, Filter.Result.DENY); flow.addAttribute ("markør", "FLOW"); console.add (flyt);

Merk at dette ny metoden tillater ikke oss å navngi filteret, men det ber oss om å indikere hva vi skal gjøre hvis filteret passerer eller mislykkes.

I dette tilfellet har vi holdt det enkelt og sa at hvis MarkerFilter passerer, da AKSEPTERER logglinjen. Ellers, BENEKTE den.

Merk i dette tilfellet at vi ikke legger dette til bygger men i stedet for appenders at vi ønsker å bruke dette filteret.

3.3. Konfigurere oppsett

Deretter la oss definere oppsettet for hver logglinje. I dette tilfellet bruker vi Mønsteroppsett plugg inn:

LayoutComponentBuilder standard = builder.newLayout ("PatternLayout"); standard.addAttribute ("mønster", "% d [% t]% -5nivå:% msg% n% kastbar"); console.add (standard); file.add (standard); rolling.add (standard);

Igjen, vi har lagt disse direkte til aktuelle appenders i stedet for til bygger direkte.

3.4. Konfigurere rotloggeren

Nå som vi vet hvor loggene skal sendes til, vil vi konfigurere hvilke logger som skal gå til hvert mål.

Rotloggeren er den høyeste loggeren, liksom Gjenstand i Java. Denne loggeren er det som skal brukes som standard med mindre den blir overstyrt.

Så la oss bruke en rotlogger for å sette standard loggnivå til FEIL og standard appender til vår stdout appender ovenfra:

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

For å peke loggeren mot en bestemt appender, gir vi den ikke en forekomst av byggherren. I stedet, vi refererer til det av Navn at vi ga det tidligere.

3.5. Konfigurere tilleggsloggere

Barneloggere kan brukes til å målrette mot spesifikke pakker eller loggernavn.

La oss legge til en logger for com pakken i applikasjonen vår, og setter loggnivået til DEBUG og at de går til vårt Logg appender:

LoggerComponentBuilder logger = builder.newLogger ("com", Nivå.DEBUG); logger.add (builder.newAppenderRef ("logg")); logger.addAttribute ("additivity", false); builder.add (logger);

Merk at vi kan stille inn additivitet med loggerne våre, som indikerer om denne loggeren skal arve egenskaper som loggnivå og appender-typer fra sine forfedre.

3.6. Konfigurere andre komponenter

Ikke alle komponenter har en dedikert ny metode på ConfigurationBuilder.

Så i så fall ringer vi newComponent.

For eksempel fordi det ikke er en TriggeringPolicyComponentBuilder, må vi bruke newComponent for noe sånt som å spesifisere vår utløsende policy for rullende filtillegg:

ComponentBuilder triggeringPolicies = builder.newComponent ("Policies") .addComponent (builder.newComponent ("CronTriggeringPolicy") .addAttribute ("plan", "0 0 0 * *?")) .AddComponent (builder.newComponent ("SizeBasedTrigger) .addAttribute ("størrelse", "100M")); rolling.addComponent (triggeringPolicies);

3.7. XML-ekvivalent

ConfigurationBuilder er utstyrt med en praktisk metode for å skrive ut tilsvarende XML:

builder.writeXmlConfiguration (System.out);

Å kjøre linjen over skriver ut:

Dette er nyttig når vi vil dobbeltsjekke konfigurasjonen vår, eller hvis vi vil fortsette konfigurasjonen, for eksempel til filsystemet.

3.8. Sette alt sammen

Nå som vi er fullstendig konfigurert, la oss fortelle Log4j 2 å bruke vår konfigurasjon:

Configurator.initialize (builder.build ());

Etter at dette er påkalt, fremtidige samtaler til Log4j 2 vil bruke vår konfigurasjon.

Merk at dette betyr at vi må påberope oss Configurator.initialize før vi ringer til LogManager.getLogger.

4. ConfigurationFactory

Nå som vi har sett en måte å få og bruke en ConfigurationBuilder, la oss ta en titt på en til:

offentlig klasse CustomConfigFactory utvider ConfigurationFactory {public Configuration createConfiguration (LoggerContext context, ConfigurationSource src) {ConfigurationBuilder builder = super .newConfigurationBuilder (); // ... konfigurere appenders, filtre, etc. return builder.build (); } public String [] getSupportedTypes () {return new String [] {"*"}; }}

I dette tilfellet, i stedet for å bruke ConfigurationBuilderFactory, vi underklasserte ConfigurationFactory, en abstrakt klasse målrettet for å skape forekomster av Konfigurasjon.

Så, i stedet for å ringe Configurator.initialize Som vi gjorde første gang, trenger vi bare å gi Log4j 2 beskjed om vår nye konfigurasjonsfabrikk.

Det er tre måter å gjøre dette på:

• Statisk initialisering
• En kjøretidseiendom, eller
• De @Plugg inn kommentar

4.1. Bruk statisk initialisering

Log4j 2 støtter anrop setConfigurationFactory under statisk initialisering:

statisk {ConfigurationFactory tilpasset = ny CustomConfigFactory (); ConfigurationFactory.setConfigurationFactory (tilpasset); }

Denne tilnærmingen har samme begrensning som for den siste tilnærmingen vi så, som er at vi må påberope den før noen samtaler til LogManager.getLogger.

4.2. Bruk en Runtime-eiendom

Hvis vi har tilgang til Java-oppstartskommandoen, støtter Log4j 2 også å spesifisere ConfigurationFactory å bruke via en -D parameter:

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

Den viktigste fordelen med denne tilnærmingen er at vi ikke trenger å bekymre deg for initialiseringsrekkefølgen slik vi gjør med de to første tilnærmingene.

4.3. Bruke @Plugg inn Kommentar

Og til slutt, under omstendigheter der vi ikke vil fikle med Java-oppstartkommandoen ved å legge til en -D, kan vi bare kommentere vår CustomConfigurationFactory med Log4j 2 @Plugg inn kommentar:

@Plugin (name = "CustomConfigurationFactory", category = ConfigurationFactory.CATEGORY) @Order (50) offentlig klasse CustomConfigFactory utvider ConfigurationFactory {// ... resten av implementeringen}

Log4j 2 skanner klassestien for klasser som har @Plugg inn kommentar, og, å finne denne klassen i ConfigurationFactory kategori, vil bruke den.

4.4. Kombinere med statisk konfigurasjon

En annen fordel ved å bruke en ConfigurationFactory utvidelse er at vi enkelt kan kombinere vår tilpassede konfigurasjon med andre konfigurasjonskilder som XML:

offentlig konfigurasjon createConfiguration (LoggerContext context, ConfigurationSource src) {return new WithXmlConfiguration (context, src); } 

De kilde parameter representerer den statiske XML- eller JSON-konfigurasjonsfilen som Log4j 2 finner hvis noen.

Vi kan ta den konfigurasjonsfilen og sende den til vår tilpassede implementering av Xml-konfigurasjon der vi kan plassere den overordnede konfigurasjonen vi trenger:

offentlig klasse WithXmlConfiguration utvider XmlConfiguration {@ Override-beskyttet ugyldig doConfigure () {super.doConfigure (); // analysere xml-dokument // ... legg til vår tilpassede konfigurasjon}}

5. Konklusjon

I denne artikkelen så vi på hvordan du bruker det nye ConfigurationBuilder API tilgjengelig i Log4j 2.

Vi tok også en titt på tilpasning ConfigurationFactory i kombinasjon med ConfigurationBuilder for mer avanserte brukstilfeller.

Ikke glem å sjekke ut de komplette eksemplene mine på GitHub.