Programmatische configuratie met Log4j 2

1. Inleiding

In deze tutorial zullen we verschillende manieren bekijken om Apache Log4j 2 programmatisch te configureren.

2. Eerste installatie

Om Log4j 2 te gaan gebruiken, hoeven we alleen de log4j-core en log4j-slf4j-impl-afhankelijkheden op te nemen in onze pom.xml:

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

3. ConfigurationBuilder

Zodra we Maven hebben geconfigureerd, moeten we een ConfigurationBuilder, dat is de klasse waarmee we kunnen configureren toevoegingen, filters, lay-outs, en houthakkers.

Log4j 2 biedt verschillende manieren om een Configuratiebouwer.

Laten we beginnen met de meest directe manier:

ConfigurationBuilder builder = ConfigurationBuilderFactory.newConfigurationBuilder ();

En om te beginnen met het configureren van componenten, Configuratiebouwer is voorzien van een bijbehorend nieuw methode, zoals newAppender of nieuwe layout, voor elk onderdeel.

Sommige componenten hebben verschillende subtypen, zoals FileAppender of ConsoleAppender, en deze worden in de API aangeduid als plug-ins.

3.1. Appenders configureren

Laten we het vertellen bouwer waar elke logregel naartoe moet worden gestuurd door een appender:

AppenderComponentBuilder console = builder.newAppender ("stdout", "Console"); builder.add (console); AppenderComponentBuilder file = builder.newAppender ("log", "File"); file.addAttribute ("bestandsnaam", "doel / logging.log"); builder.add (bestand);

Terwijl de meeste nieuw methoden ondersteunen dit niet, newAppender (naam, plug-in) stelt ons in staat om de appender een naam te geven, die later belangrijk zal blijken te zijn. Deze appenders hebben we gebeld stdout en logboek, hoewel we ze alles hadden kunnen noemen.

We hebben ook de bouwer welke appender inpluggen (of, eenvoudiger, welk soort appender) te gebruiken. Troosten en het dossier verwijs naar de appenders van Log4j 2 voor respectievelijk het schrijven naar standard out en het bestandssysteem.

Hoewel Log4j 2 verschillende appenders ondersteunt, het configureren ervan met Java kan een beetje lastig zijn, omdat AppenderComponentBuilder is een generieke klasse voor alle typen appender.

Dit zorgt ervoor dat het methoden heeft zoals attribuut toevoegen en addComponent in plaats van setFileName en addTriggeringPolicy:

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

En tenslotte, vergeet niet te bellen builder.add om het toe te voegen aan de hoofdconfiguratie!

3.2. Filters configureren

We kunnen filters toevoegen aan elk van onze appenders, die op elke logregel beslissen of deze al dan niet moet worden toegevoegd.

Laten we de MarkerFilter plug-in op onze console-appender:

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

Merk op dat dit nieuw methode staat ons niet toe om het filter een naam te geven, maar het vraagt ​​ons wel om aan te geven wat te doen als het filter slaagt of faalt.

In dit geval hebben we het simpel gehouden door te stellen dat als het MarkerFilter passeert dan AANVAARDEN de loglijn. Anders, ONTKENNEN het.

Houd er in dit geval rekening mee dat we dit niet aan het bouwer maar in plaats daarvan aan de appenders dat we dit filter willen gebruiken.

3.3. Lay-outs configureren

Laten we vervolgens de lay-out voor elke logregel definiëren. In dit geval gebruiken we de PatternLayout inpluggen:

LayoutComponentBuilder standard = builder.newLayout ("PatternLayout"); standard.addAttribute ("patroon", "% d [% t]% -5level:% msg% n% throwable"); console.add (standaard); file.add (standaard); rolling.add (standaard);

Nogmaals, we hebben deze rechtstreeks aan de juiste toevoegingen toegevoegd in plaats van aan de bouwer direct.

3.4. De Root Logger configureren

Nu we weten waar logboeken naartoe worden verzonden, willen we configureren welke logboeken naar elke bestemming gaan.

De rootlogger is de hoogste logger, zoiets als Voorwerp in Java. Deze logger wordt standaard gebruikt, tenzij deze wordt overschreven.

Laten we dus een root-logger gebruiken om het standaard logboekregistratieniveau in te stellen FOUT en de standaard appender naar onze stdout appender van boven:

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

Om onze logger op een specifieke appender te richten, geven we hem geen instantie van de builder. In plaats daarvan, we verwijzen ernaar met de naam dat we het eerder hebben gegeven.

3.5. Extra loggers configureren

Child-loggers kunnen worden gebruikt om specifieke pakketten of logger-namen te targeten.

Laten we een logger toevoegen voor de com pakket in onze applicatie, waarbij u het logniveau instelt op DEBUG en die naar onze te laten gaan logboek appender:

LoggerComponentBuilder logger = builder.newLogger ("com", Level.DEBUG); logger.add (builder.newAppenderRef ("log")); logger.addAttribute ("additiviteit", false); builder.add (logger);

Merk op dat we kunnen instellen additiviteit met onze loggers, wat aangeeft of deze logger eigenschappen zoals logging niveau en appender types van zijn voorouders zou moeten erven.

3.6. Andere componenten configureren

Niet alle componenten hebben een dedicated nieuw methode op Configuratiebouwer.

Dus in dat geval bellen we nieuwComponent.

Bijvoorbeeld omdat er geen TriggeringPolicyComponentBuilder, we moeten gebruiken nieuwComponent voor zoiets als het specificeren van ons activeringsbeleid voor het toevoegen van rollende bestanden:

ComponentBuilder triggeringPolicies = builder.newComponent ("Policies") .addComponent (builder.newComponent ("CronTriggeringPolicy") .addAttribute ("schedule", "0 0 0 * *?")) .AddComponent (builder.newComponent ("SizeBolasedTriggering) .addAttribute ("size", "100M")); rolling.addComponent (triggeringPolicies);

3.7. Het XML-equivalent

Configuratiebouwer is uitgerust met een handige methode om de equivalente XML af te drukken:

builder.writeXmlConfiguration (System.out);

Het uitvoeren van de bovenstaande regel wordt afgedrukt:

Dit is handig als we onze configuratie dubbel willen controleren of als we onze configuratie willen behouden, bijvoorbeeld in het bestandssysteem.

3.8. Alles samenvoegen

Nu we volledig zijn geconfigureerd, laten we Log4j 2 vertellen om onze configuratie te gebruiken:

Configurator.initialize (builder.build ());

Nadat dit is aangeroepen, toekomstige oproepen naar Log4j 2 zullen onze configuratie gebruiken.

Merk op dat dit betekent dat we een beroep moeten doen op Configurator. Initialiseren voordat we bellen naar LogManager.getLogger.

4. ConfigurationFactory

Nu we een manier hebben gezien om een Configuratiebouwer, laten we er nog een bekijken:

openbare klasse CustomConfigFactory breidt ConfigurationFactory uit {openbare configuratie createConfiguration (LoggerContext-context, ConfigurationSource src) {ConfigurationBuilder-builder = super .newConfigurationBuilder (); // ... configureer appenders, filters, etc. return builder.build (); } public String [] getSupportedTypes () {retourneer nieuwe String [] {"*"}; }}

In dit geval, in plaats van te gebruiken ConfiguratieBuilderFactory, hebben we onderverdeeld ConfigurationFactory, een abstracte klasse bedoeld voor het maken van instanties van Configuratie.

Dan, in plaats van te bellen Configurator. Initialiseren zoals we de eerste keer deden, hoeven we Log4j 2 gewoon op de hoogte te stellen van onze nieuwe configuratiefabriek.

U kunt dit op drie manieren doen:

  • Statische initialisatie
  • Een runtime-eigenschap, of
  • De @Inpluggen annotatie

4.1. Gebruik statische initialisatie

Log4j 2 ondersteunt bellen setConfigurationFactory tijdens statische initialisatie:

statische {ConfigurationFactory custom = new CustomConfigFactory (); ConfigurationFactory.setConfigurationFactory (aangepast); }

Deze benadering heeft dezelfde beperking als voor de laatste benadering die we hebben gezien, namelijk dat we er een beroep op moeten doen voordat u belt naar LogManager.getLogger.

4.2. Gebruik een Runtime-eigenschap

Als we toegang hebben tot de Java-opstartopdracht, ondersteunt Log4j 2 ook het specificeren van de ConfigurationFactory te gebruiken via een -D parameter:

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

Het belangrijkste voordeel van deze benadering is dat we ons geen zorgen hoeven te maken over de initialisatievolgorde, zoals bij de eerste twee benaderingen.

4.3. Gebruik de @Inpluggen Annotatie

En tot slot, in omstandigheden waarin we niet met de Java-opstartopdracht willen spelen door een -Dkunnen we eenvoudig onze CustomConfigurationFactory met de Log4j 2 @Inpluggen annotatie:

@Plugin (name = "CustomConfigurationFactory", categorie = ConfigurationFactory.CATEGORY) @Order (50) public class CustomConfigFactory breidt ConfigurationFactory uit {// ... rest van implementatie}

Log4j 2 scant het klassenpad voor klassen met de extensie @Inpluggen annotatie, en het vinden van deze klasse in de ConfigurationFactory categorie, zal het gebruiken.

4.4. Combineren met statische configuratie

Een ander voordeel van het gebruik van een ConfigurationFactory uitbreiding is dat we onze aangepaste configuratie gemakkelijk kunnen combineren met andere configuratiebronnen zoals XML:

openbare configuratie createConfiguration (LoggerContext context, ConfigurationSource src) {retourneer nieuwe WithXmlConfiguration (context, src); } 

De bron parameter vertegenwoordigt het statische XML- of JSON-configuratiebestand dat Log4j 2 vindt, indien aanwezig.

We kunnen dat configuratiebestand nemen en naar onze aangepaste implementatie van XmlConfiguration waar we elke overheersende configuratie kunnen plaatsen die we nodig hebben:

openbare klasse WithXmlConfiguration breidt XmlConfiguration uit {@Override beschermde leegte doConfigure () {super.doConfigure (); // ontleden xml-document // ... voeg onze aangepaste configuratie toe}}

5. Conclusie

In dit artikel hebben we gekeken hoe we het nieuwe ConfigurationBuilder API beschikbaar in Log4j 2.

We hebben ook gekeken naar maatwerk ConfigurationFactory in combinatie met ConfigurationBuilder voor meer geavanceerde gebruiksscenario's.

Vergeet niet mijn volledige voorbeelden te bekijken op GitHub.


$config[zx-auto] not found$config[zx-overlay] not found