I have a Maven project, running correctly. I am using a log4j2.xml file to configure the logging. Until today everything was working fine. But now, I have included a dependency of a third-party jar that has its own log4j2.properties file. Unfortunately, this is overwritting my own configuration.
Is there any way I can ignore, exclude... that property file?
Actually, the other answers are incorrect as they are advising you to use the system property log4j 1.x uses, not what Log4j 2 uses.
For Log4j 2 you want to use -Dlog4j2.configurationFile=/path/to/log4j2.xml. If you only specify -Dlog4j2.configurationFile=log4j2.xml then Log4j will look for that file on the class path. Obviously the name can be anything you want. Log4j also supports putting the system properties in a file named log4j2.component.properties so if you do not want to specify them on the command line you can include them in a Java Properties file with that name in your application.
No matter what you do you should open a bug with the third party as putting a logging configuration file in a library jar is a bad practice.
You can add an option to specify your own log4j properties file with
-Dlog4j.configuration=path/to/my.properties
and thats better than excluding everytime a new library tries to override your properties file.
Related
Currently when I execute my code I it doesn't create any log file.
the logback.xml is configured fine, however I don't see a way to configure where to find the xml file
Per the Logback manual chapter on Configuration:
Let us begin by discussing the initialization steps that logback follows to try to configure itself:
Logback tries to find a file called logback-test.xml in the classpath.
If no such file is found, logback tries to find a file called logback.groovy in the classpath.
If no such file is found, it checks for the file logback.xml in the classpath.
If no such file is found, service-provider loading facility (introduced in JDK 1.6) is used to resolve the implementation of com.qos.logback.classic.spi.Configurator interface by looking up the file META-INF\services\ch.qos.logback.classic.spi.Configurator in the class path. Its contents should specify the fully qualified class name of the desired Configurator implementation.
If none of the above succeeds, logback configures itself automatically using the BasicConfigurator which will cause logging output to be directed to the console.
The standard approach that this is trying to tell you about would be to have logback.xml be in the classpath for "normal" running, and have a logback-test.xml in the classpath to describe how you want to log when running automated tests. (For example, you may want to log to a file in your regular application, but have your automated unit tests just log to the console.) The exact process of putting a file into the classpath depends on what build system you're using. For example, with the default settings in the popular Maven build system, you would put logback.xml inside src/main/resources, and (if desired) a logback-test.xml inside src/test/resources. If you're having trouble with this step, you may want to search for or ask another question with more details about the build toolchain you're using. Also be sure to read "What is a classpath?"
Another approach, also listed in the Logback manual:
You may specify the location of the default configuration file with a system property named "logback.configurationFile". The value of this property can be a URL, a resource on the class path or a path to a file external to the application.
java -Dlogback.configurationFile=/path/to/config.xml chapters.configuration.MyApp1
Note that the file extension must be ".xml" or ".groovy".
This wouldn't be as common, but sometimes if you need to run in a particular environment with a certain logging configuration, or run some sort of automated test directing output to a different place than your normal tests, it can come in handy to just outright configure the path like that.
I have a concern that where do we have to put log4j.properties file when packaging to jar file by using maven.what is the best practice here.
General recommendation
Put it into src/main/resources. You may want to define a more verbose log4j configuration in src/test/resources, if you do use junit tests.
See maven standard directory layout.
Setting a new configuration for specific executions
If you want to create an executable jar with a main method, you can ship a default configuration in src/main/resources and still provide an overriding log configuration when starting your jvm, using this jvm parameter: -Dlog4j.configuration=file:"<FILE_PATH>".
Building for multiple environments
You can also create multiple subfolders in your resource configuration and have the maven resource plugin copy the correct log4j.xml to the destination via maven profiles.
Observed a rather strange behaviour from apache log4j and thought sharing to get your thoughts.
I have an application which I'm running using an script. So far nothing special about that.
But the CLASSPATH I'm setting using that script, say a directory /home/myName/, have two different log4j properties files. One is simply log4j.properties and other is log4jXYZ.prperties.
The strange thing is when I run this script from different directories, one or the other log4j properties file is being picked-up. My understanding was it should have picked log4j.properties, obviously irrespectively from whereever I run the script.
Do you see some logic which can make a sense of it. Currently I'm at loss.
What I can predict is that log4j is trying any file matching lo4j*.properties expression.I must admit I haven't read all the manual assisting log4j.
Add log4j.debug property, when you run the application (-Dlog4j.debug= for the java command), it should show you the path where it loads the config file from.
I suspect it may load a file with same name from another directory than you think.
There are 2 log4j.properties files in my classpath. I need both of them - One of them is required for a library that I am using and another is the one used by my code. When I run my jar file, it is able to read the properties used by the library, but it is not reading my own properties file. How can I make it read my log4j without having to use PropertytConfigurator in all my source files? Is there any way I can configure it so that it used both the properties files together?
To answer your first question, you can point it to your own file by giving it a unique name and adding the following system property when you launch your application.
-Dlog4j.configuration=path_to_my_properties_file
I don't think it is possible to use 2 different files without doing anything programatically.
Two log4j.properties files will surely create a mess (as you've experienced).
I'd suggest removing the library's version (why is it a requirement?), and combining both .properties files into one.
All logging goes into a single property file. Within that file you can differentiate between your own classes and the library's logging configuration.
I have a main project, which depends on multiple projects (in eclipse).
At the end of the project, I will generate a runnable jar and a log4j.properties. This properties file is an external file, so my client can modify it at will (email address etc).
runnable.jar + log4j.properties.
At the same time, those projects which the main project depends on, have their own log4j properties files.
I want to centralize the setting in log4j.properties into one external file. How to do that?
If you add a JVM parameter -Dlog4j.configuration="file://anywhere/anyfile", all your components will use the same configuration. You can combine all your log4j configuration in this one big file. Is this what you mean by centralizing?
You will have to copy the relevant settings of the log4j.properties from the other projects into your file. But I guess the real question is: Why would you want to do that? Normally you would not care about logging those other projects in detail. A general root level should cover them just fine. And if you do care, you should care in a way that is different from their default.