As above, can log4j2 be configured at the same time with .xml and .properties?
And if it can, what takes priority, when changing shared configuration?
This is the direct answer
Firstly: Why would you want to have multiple configuration files? Seems to me like you should try to collate all of your configuration into one file if at all possible.
The documentation for Log4J2 says that the automatic configuration will search first for the System property "log4j.configurationFile", which points to one configuration file on the file system, which is loaded based on the type of file.
If that isn’t found, it will search for:
.properties
.yml
.json
.xml
In that order.
This to me means that you can only use one.
This provides another approach
You can, however programmatically configure the logger, which can combine a configuration file with a different set of configurations.
If you wanted to combine the Configurator method with XML configuration, for example, then apparently you have to use the ConfigurationFactory, which is something I have never done before, though if you understand the layout of the Log4J2 it doesn't look too difficult - basically extending ConfigurationFactory, overriding methods to configure things, then giving the Configurator the factory.
Additional links:
Here is the programmatic configuration documentation
Here is a helpful Baeldung articl for programmatic configuration
Related
I am working on a huge application which uses its on property file to set the global variables. I want to use the same one for setting the properties of Log4j log file instead of log4j.properties file due to some problems. How do I do this? Is there any way to set the properties of Log4j at run time?
If you just want to rename your log4j.properties file you can do this using a System Variable in your JVM startup (refer link)
-Dlog4j.configuration=test.properties
The Log4j API also allows configuration changes to the Loggers from within an application. Theoretically you could read your own property file and call the appropriate API calls. I'm not sure this approach is recommended - you might end up spending a lot of time getting it working that you could better use developing your application functionality.
Note: I dont know the nature of the huge application, but it if its running in an application server such as JBoss they often have their own dynamic logging configuration
I'm using a jar that has log4j.properties included. One property of this jar maps to a static local resource with a path that does of course not exist on my system.
Problem: my custom log4j.properties is somehow not taken into account, even thought it is on the classpath.
What do I have to change so that the existing log4j from the jar remains valid, but only a specific value is overridden with my custom log4j?
log4j.appender.InfoFileAppender.File=d:/logs/info.log
To start with, Log4j should create the new file for you in most of the conditions. And if it cannot, read below.
By default, Log4j will load the first found "log4j.properties" in your class-path.
So in your case,
a) if you want to load a custom log4j property file of the name "log4j.properties" with changes, make sure that it appears first in your class-path order.
b) You can load multiple custom log4j settings from different files using the PropertyConfigurator provided by Log4j. Even if you do this, i don't think you can override a particular property of an appender, because log4j wont load an appender again if it is already loaded.
c) The best approach would be to reassign a new file to the appender programmatically during the start up of your application.So you should have a piece of code which execute during startup which uses the Logger API's to gets the appender of the required logger and reset it.
Ok, in general,i say your use case is to validate the file existence before an appender is created,
you can add that validation check using a custom Configurator.
Log4j will use PropertyConfigurator to load your log4j.properties. You can define your own Configurator implementation which extends from Propertyconfigurator and write the code to make sure that appender file location is a valid one, and if not valid set it to a different one.
Make sure that you set the system property log4j.configuratorClass to tell Log4j that your Configurator should be loaded. Here i think you just need to override the parseAppender method from PropertyConfigurator.
Old topic, but maybe useful for others who stumble upon it. I managed to overwrite a certain property this way:
http://aadityatiwari.com/2013/08/override-log4j-properties-at-runtime/
Of course, this won't help in your scenario, because you need to read the log4j.properties in memory first to override it.
Hi I came across some code which is using log4j. I want to move to log4j2.
From http://logging.apache.org/log4j/2.x/manual/migration.html I came to that log4j-1.2-api.jar can be used. I have following question :
In code I have a custom appender (as given in that link I should not use internals of class Appender) is that mean I can't use log4j-1.2-api.jar ?
I also want to use asyn logging feature of log4j2 . How do I do that using log4j-1.2-api.jar.
Your custom appender may no longer work. Log4j2 has a lot of functionality, and depending on what your custom appender did, it could be that this functionality already exists in log4j2. You can ask on one of the mailing lists and if it is a function that could be useful for many users it may be added to log4j2.
To use the async loggers, you can either make all loggers async with a system property (http://logging.apache.org/log4j/2.x/manual/async.html#AllAsync) or mix synchronous and async loggers with configuration (http://logging.apache.org/log4j/2.x/manual/async.html#MixedSync-Async). Both should work when you drop in the log4j-1.2-api jar (in addition to the log4j-api and log4j-core jars, these two jars are always needed).
There is a migration guide. I used it successfully.
http://logging.apache.org/log4j/2.x/manual/migration.html
In log4j2 everything is cofigured using a XML file (or more XML files, e. g. for your test directory). The file should be named log4j2.xml.
I need to create separate logs for different object instances in my applications. For example if we work with books, i need separate log file for every book. It works fine with log4j2.xml file, but i may have hundreds of such objects in memory and i don't want to create such a long configuration file. I want to create appenders and loggers from code. I looked for working code example and found nothing.
I tried to use RollingFileAppender.createAppender but didn't found how to attach it to logger and failed to get proper values for this function parameters.
Please help with working code\configuration how to create separate log files per object property.
Probably it can be done with wildcards in appender\logger names in log4j2.xml or using renderer?
If splitting log file base on "book" is what you are looking for, instead of creating a very specific appender or configure log4j programmatically to deal with that, you should have a look at MDC.
With proper MDC setup, it should be straight-forward to split log files base on MDC content (e.g. in LogBack, there is a SiftingAppender. I believe there is similar 3rd-party appenders that do the same thing)
You could use the static method #initialize(String contextName, ClassLoader loader, String configLocation) (see source here) in org.apache.logging.log4j.core.config.Configurator.
(You can pass null for the class loader.)
Be aware that this class is not part of the public API so your code may break with any minor release.
We can use both Spring config file OR a .properties file to store and retrieve some properties, like for a database connection. (db url, db password and etc)
We can also use Spring config file and a .properties file together, where we reference the property from a .property file (like in ant)
What would be the advantages or disadvantages for the following scenarios:
1 - Using only .properties file.
2 - Using only Spring config file.
3 - Using both together.
Would any of the scenarios be better when it comes to maintenance?
I need to choose between the three, and I would like to have a better judgement before I go with any of the option!
Thanks in advance!
- Ivar
Both together. Use a properties file that's externalizable from your project to configure Spring. Spring then configures your project. Mostly, you don't write code to read from properties files. Let Spring manage that and inject your objects with the appropriate values. Then you have appropriate dependency injection and the artifact you build isn't environment-specific.
Disadvantages:
How does your code know what file to load the properties from? Isn't that a property? It also violated dependency injection by having code go find a resource rather than passively accepting one.
Configuration is tightly coupled to your artifact and can't change between environments without rebuilding (BAD).
The way you seem to think of it, this combines the disadvantages of the other two, but if you do it the way I described, it eliminates those disadvantages, which is an advantage.