Condition logging level in Log4j.properties

Question

Is it possible to have conditions in log4j.properties. I have a situation where I want to have logging level set to Info on production environment and DEBUG on local. Is it possible to read environment variables in log4j.properties.

Try to use a two versions of log4j properties for your environments and place them out of application and add to classpath — Keerthivasan, Nov 15 '13 at 06:49
log4j can also be controlled programmatically - maybe not what you want though — Scary Wombat, Nov 15 '13 at 06:51
Thanks for the answer, I am using this approach in one of my webapps, but this leads to redundency, I was wondering if there was any way to make it conditional — Vineet Kasat, Nov 15 '13 at 06:52
But, i prefer them that way. I can manage them following a good naming convention. for example, log4j-dev.xml, log4j-prod.xml indicating the environment in the file name — Keerthivasan, Nov 15 '13 at 06:55

score 3 · Answer 1 · answered Nov 15 '13 at 06:52

3

No, you have to have 2 different log4j.properties file

answered Nov 15 '13 at 06:52

Surendran Duraisamy

2,431
5
26
29

score 2 · Answer 2 · answered Nov 15 '13 at 07:06

Configuring logging is something that should happen as part of the deployment, not as part of the build, i.e. you should NOT create multiple builds for different log configurations, the risk of introducing also other differences in artifacts is to big.

Create ONE build containing a default configuration, possibly the one you want to use in production.

Implement a way to find and use an alternative configuration without changing your artifact. Most of the time this is achieved by adding an additional directory to the classpath of your application and store a log4j configuration there. You can use the default initialization of log4j by using a configuration format that has higher precedence then the one contained in the artifact. This also allows you to reconfigure logging without new deployment, which can be very helpful when troubleshooting.

Alternatively you can provide the location of the configuration file to use via a environment variable at startup: -Dlog4j.configuration=log4j-prod.xml (borrowed from Keerthi Ramanathan's answer)

score 1 · Answer 3 · answered Nov 15 '13 at 06:56

1

You can prepare different builds and decide which log4j.propeties you want to include on build time, for example using maven params, profiles or any other way. There is no way to declare condition in log4j.properties

answered Nov 15 '13 at 06:56

Yegoshin Maxim

872
2
21
54

1

This might be usefull for Standalone-Applications where you dont have access to the configuration of the Container. If you use Tomcat ie. and you have access to the configuration its more flexible to not include the log4j.properties into the webapp and configure the logging indirectly via the container. – Grim Nov 15 '13 at 07:02

score 1 · Answer 4 · answered Nov 15 '13 at 07:11

No. But just to outline some other options

a) I would encourage you to have a look at logback which provides a simple facade over log4j and you can then change your config at runtime. The relevant documentation can be found here.

b) If you have a build process in place (ant/maven) you can do the replacement as part of the build process. If you use maven you can set up a profile to build and the in the build-cycle apply filtering

c) Load the log4j files from a conf directory for each environment. The idea for that is that the files once set for an environment are changed minimally over time. You maintain both in your repository and as part of your deployment process ensure that additional/deleted files/props get added/removed.

score 0 · Answer 5 · answered Nov 15 '13 at 07:01

0

What i would suggest as said in comment, have a separate version of log4j properties file for every environment and follow the naming convention for easy maintainance. say, for dev environment, it would be log4j-dev.xml and for production, log4j-prod.xml. Now, you can configure the appropriate file to pick up during runtime using

-Dlog4j.configuration=log4j-prod.xml

during server startup. so, that appropriate conffiguration file will be taken by log4j.

answered Nov 15 '13 at 07:01

Keerthivasan

12,760
2
32
53

In addition to your answer, We can maintain multiple log4j files and on build time on the basis of environment chose the required one. – Vineet Kasat Nov 15 '13 at 07:04
1

Yes, that would be great using ANT or something like that.cool. – Keerthivasan Nov 15 '13 at 07:05

score 0 · Answer 6 · edited May 23 '17 at 12:05

0

You can use programmatic configuration when using log4j, which gives you more control over what options to use in what environment. You can have your own configuration files and use your own logic to convert them into a log4j configuration. The downside is that you need to do init() somewhere in your application. This answer provides good reference.

edited May 23 '17 at 12:05

Community

1
1

answered Nov 15 '13 at 07:02

Alfred Xiao

1,758
15
16

score 0 · Answer 7 · answered Nov 19 '18 at 22:23

I used a this approach when I had similar question. A default log level if nothing is explicitly specified, and option to override.

So, I added a log4j.properties file in application resources.

log4j.rootLogger=ALL, stdout
...
log4j.appender.stdout.Threshold=INFO
...

And then added more log config properties (log4j-n.properties, for n in {d, i, w, e}) defining log levels at debug, info, warning and error. Now, during startup I would supply the config file explicitly if I wanted to override the default.

java ... -Dlog4j.configuration=file:///<path>/log4j-n.properties ...

This would override any config I had in the default log4j.properties.

Later I went with this approach. I removed all the extra config files. In the log4j.properties file in resources, I used a JVM arg placeholder:

log4j.appender.stdout.Threshold=${app.log.level}

And supplied that as JVM argument.

java ... -Dapp.log.level=<LOG-LEVEL> ...

Voila!

Condition logging level in Log4j.properties

7 Answers7