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.
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 want to write a text file at classpath. want to make some changes in that file.
this is spring boot application and packaging it as a jar. So basically this text file is located in jar & I want to make changes to that file.
Don't know it is possible or not.
but please suggest to me how I can do that?
Files inside a jar can be read from (called resource files in general).
You cannot modify them directly though. For that, you need them to be outside the jar.
Possible duplicate of Updating resource files at runtime
If it is a .properties file though, there are ways to do it.
Following blog seems helpful (https://crunchify.com/java-properties-files-how-to-update-config-properties-file-in-java/)
I have no idea as to where to include the .jar file of mysql-connector/j using tomcat8.0.33. One of the blogs have mentioned to include in $CATALINA_HOME/common/lib, but i am not able to find "common".
And also could anyone please tell me how to create context configuration file for tomcat.
In the $CATALINA_HOME/conf, examine the catalina.properties file. There are definitions for where it will look for .jar files.
You can make the directory $CATALINA_HOME/common/lib, but it also must be loaded in one of the loaders defined in that .properties file. We actually make the common/lib, and modify the .properties, but there are differences of opinion on that approach.
You should also be aware of some differences in the loading because of the class loaders that are used by the different defined loaders.
I believe you are safe (in terms of it being found) in placing the MySQL library in the $catalina_base/lib directory, which I believe is included by default in the common.loader.
Copy it to $TOMCAT\lib folder.but that depends where to connection are to be managed.
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.
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.