while running my test cases in unix enivornment which are supported by testng framework ,I want to change the log level of log4j2 properties file through the command line.Is there any way to do this.
You can use JVM property log4j.configuration to specify custom log4j configuration file, e.g.:
java -jar .... -Dlog4j.configuration=/home/log4j.properties
That file should contains specific setting for Unit tests
Related
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.
I'm trying to use application properties, other than application.properties, say application_local.properties within resources directory.
So that I can have 2 properties files, one for local and other the server.
As mentioned in many blogs, I should use below command:
spring-boot:run -Dspring.config.location=/Users/myuser/work/MyProject/my-app/src/main/resources/application_local.properties
But this is not working, it is still fetching values from application.properties.
What am I missing, please suggest?
Thanks
1- Follow the naming convention application-{profile}.properties
application-local.properties
2-set profile
-Dspring.profiles.active=local
Briefly, you can use these two links:
How to load property file based on spring profiles
spring-profiles
-Dspring.profile.location takes directory as input. The purpose of this property is to specify additional directory location to keep your property files.
You are using property file name in your command.
Refer to detailed # Answer at other thread here
Instead you can use as suggested by #mehardad
The -D option will send parameters to Java virtual machine. In order to send parameters to Spring boot, the command option of '--' must be used.
Example:
Suppose, there is an option named 'spring.profiles.active' defined in the application.properties file as follows:
spring.profiles.active=dev
This option can be overwritten using command line parameter as follows:
java -jar application.jar --spring.profiles.active=prod
Use Spring profiles and choose at runtime, locally would
-Dspring.profiles.active=local
The property file should be called application-local.properties
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.
is it possible to specify the logging level for java.util.logging using classpath? I don't want to use for that special file or create java class which overrides the default level.
My point is to say something like this -Djava.util.logging.level=ERROR
I can't find it in documentation, but maybe there are some tricks for that.
No, it is not possible. The Java Logging API can be configured either with a configuration class java.util.logging.config.class or with a configuration file. A default logging configuration file is located at "lib/logging.properties", inside the JRE directory.You could change this configuration file (which is not the best idea as it will be used for all the programs running in this JRE) or
you could set a separate configuration file for your application and set JVM property java.util.logging.config.file to point to this file
-Djava.util.logging.config.file=/tmp/logging.properties
See this tutorial for more details on Java Logging configuration.
I am new to Java logging API and need some help with this problem:
While creating the application, my config file was stored in the project root folder, so I used -Djava.util.logging.config.file=logging.properties switch to run the program.
But then I exported the executable JAR.
How to configure the logging now? It doesn't work, when I specify the path to config file with the -D switch.
You can't specify JVM arguments into the MANIFEST.MF file so you have to specify the logging properties at the command line or with a shortcut :
java -Djava.util.logging.config.file=logging.properties -jar yourjar.jar
Otherwise you could package a properties file(logging.properties in your case) in the JAR, read that at
startup and put those settings into the system properties.
The javadoc says:
In addition, the LogManager uses two optional system properties that
allow more control over reading the initial configuration:
"java.util.logging.config.class"
"java.util.logging.config.file"
These two properties may be set via the Preferences API, or as command
line property definitions to the "java" command, or as system property
definitions passed to JNI_CreateJavaVM.
If the "java.util.logging.config.class" property is set, then the
property value is treated as a class name. The given class will be
loaded, an object will be instantiated, and that object's constructor
is responsible for reading in the initial configuration. (That object
may use other system properties to control its configuration.) The
alternate configuration class can use readConfiguration(InputStream)
to define properties in the LogManager.
So, either use the java.util.logging.config.file system property, and store the config file out of the jar file (which is probably a good idea if you want to be able to customize the logging properties in order to debug or analyze some weird behavior), or store the config file wherever you want (in the jar file, for example), and use the java.util.logging.config.class system property to load and instantiate a class that will read the file in the jar file (Using Class.getResourceAsStream()).
I know it's little late to answer this question but I ran into this issue few days back with the runnable jar and I solved it like this:
java -Djava.util.logging.config.file=logging.properties -cp test.jar com.sample.test.Main
where test.jar is the name of your jar and com.sample.test.Main is the fully qualified name of your main class.