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.
Related
I have two different log4j.properties files. One is for production and the other one is for sandbox. Normally, application uses log4j.properties. But for sandbox version (by using a condition) I want that application should use a properties file which is created by me and named as sandbox-log4j.properties. Only difference between them is a log tracking line is added to sandbox version.
How could I make a switch between two files by using a conditin in a java file?
I found the answer. #Michael's suggestion on JVM helped me to handle the problem. I use Elastic Beanstalk and its JVM options field on Configuration provided to separate log4j.properties files. Setting JVM options to -Dlog4j.configuration=sandbox-log4j.propertiesis enough for solution.
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.
We'd like to configure ESAPI property files directory, in JBOSS WildFly
(What usually done by VM argument: -Dorg.owasp.esapi.resources="/path/to/.esapi")
but prefer to do so in OTHER way, to suppurt diffrent property configuration for diffrent projects
does someone know how to do so?
Thaks!
There's really only two methods for loading these files, neither of them care about the application server you use. The first method, as you suggested is to supply the path via JVM properties.
The second method is via the classpath. I've never worked in JBOSS, but in Weblogic there's a config menu where you can place files on the classpath directly. In your case, it sounds like you want a different properties file for multiple applications? A JVM property or a similar classpath edit to weblogic would be the only choices.
The final classpath method, which I'm only including to be complete, is to compile your own copy of the library with your properties files in src/main/resources. Or--really hacky--crack open the jar file and dump them in by hand. The benefit of the "compile yourself" approach is that you'll have all the unpublished bugfixes, so if another CWE gets assigned to it you don't have to wait for the official release.
I have a maven project with several dependencies and use log4j.properties to control output. In some cases the same class may be referenced in different property files with different parameters. Is there a defined protocol for "overriding" properties or does it depend on the order in which packages are loaded?
(I am locating all log4j.properties directly under src/main/resources - is this the correct place?)
UPDATE:
I have accepted #Assen's answer as it makes sense though it doesn't make the solution easy. Essentially he recommends excluding log4j.properties from the jar. In principle I agree, but it puts the burden on the user to control the output and most of my users don't know what Java is, let alone properties files.
Maybe there is a way of renaming the properties files in each jar and using a switch (maybe with -D) to activates the properties.
I often have similar discussions on projects. I thing log4j.properties is typically something you want to keep out of the application, and not pack it in a war and deliver it together with the code. Logging configuration:
is environment specific. When you write the application, you simply can't define the appenders that will be desired, file locations etc.
its lifecycle is totally different than the application's. After an application is deployed, logging properties can be changed several times a day. Redeploying the application shouldn't override your last logging settings.
Why package logging configuration together with your code then? I usually keep somewhere a configuration folder, with soubfolders like 'dev', 'test-server-01', 'macbook-john' etc. Each subfolder contains list own copy of log4j.properties. None of them is included in the build artifact - jar or war.
When deploying, one of thuse subfolders is delivered separately. For the test server 1, this would be the content of test-server-01 subfolder. Dependng on the application server used, thers is a different trick tu put some files on the classpath.
When developing, I take care to set one of those subfolders on the path. When John develops on his macbook, he might want to put 'macbook-jihn' on the classpath, or create a new one. He can change logging settings and commit without conflicts.
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.