Loading log4j2.xml or properties configuration file during runtime by specifying path

Question

I am trying to load log4j2.xml or properties file from a specific location which will be provided at runtime. This is part of a migration from log4j 1.x to log4j 2.x version. I have seen there are lots of changes in the logging configuration loading sequences in log4j2. So right now after searching I have the following methods below -

1 -

 Configurator.reconfigure(new URI("URI of your file"));

2 -

// import org.apache.logging.log4j.core.LoggerContext;
LoggerContext context = (org.apache.logging.log4j.core.LoggerContext) LogManager.getContext(false);
File file = new File("path/to/a/different/log4j2.xml");

// this will force a reconfiguration
context.setConfigLocation(file.toURI());

But they say that LoggerContext class is not part of the public API, is it still the case now ?

3-

InputStream inputStream = new FileInputStream("C:/path/to/log4j2.xml");
ConfigurationSource source = new ConfigurationSource(inputStream);
Configurator.initialize(null, source);

4- Or simply

Configurator.initialize(null, "/path/to/log4j2.xml");

I am confused if all of these are viable or are to be used in different scenarios and have different outcomes.

Also the functions that I am trying to replace are DOMConfigurator and PropertyConfigurator. I know log4j2 will find configurations automatically in classpath but incase I have multiple configuration files for different environments etc or scenarios or the configuration file is outside the classpath, somewhere else on the system - I am trying to use these above functions to do it. Please help as I am stuck here, thank you.

Answer 1

If no LoggerContext is associated with the caller, all these methods have the same effect: they create a LoggerContext and configure it using the configuration source provided.

The 4 methods start to differ if there is a LoggerContext associated with the caller. This can happen if any LogManager's get* method was called before (e.g. in a static initializer). If this happens, the first two methods will replace that context's configuration, while the last two are no-ops.

PropertyConfigurator and DOMConfigurator in Log4j 1.x worked differently: unless you used log4j.reset=true key they modified the previous configuration. Although the two classes have been ported to the newest log4j-1.2-api, the "reset" semantic is not implemented and they behave like Configurator.reconfigure restricted to a single configuration format.

Remark: Configurator.reconfigure tries to guess the configuration format to choose the appropriate ConfigurationFactory. Since both Log4j 2.x and Log4j 1.x have the properties and XML formats, all properties and XML files will interpreted as native Log4j2 configuration files. Check this question for a workaround.