try not to hardcode log4j configurations
Written on September 2, 2007 – 12:00 am | by mpayne
Around work, I’ve seen applications where there are
several log4j configurations checked in along side each other(dev,
test, prod). Often, the only differences are location of where the log
files go.
A better solution would not require, .war files to be re-built in order
to only change log file destinations. Log4J will interpret variables
given to it.
e.g. ${LOG_HOME}/mylog.txt
<appender name="FILE" class="org.apache.log4j.FileAppender">
<param name="File" value="${LOG_HOME}/mylog.txt"/>
<param name="Append" value="false"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%t] %C{2} (%F:%L) - %m%n"/>
</layout>
</appender>
To supply this value to tomcat set variable "CATALINA_OPTS". e.g.
CATALINA_OPTS=-DLOG_HOME=/usr/java/logs
export CATALINA_OPTS
(before calling catalina.sh run)
or on windows
SET CATALINA_OPTS=-DLOG_HOME=/usr/java/logs
(this can also be set via system environment settings in the control panel).
I like this solution better than hard coding the path or referring to ${CATALINA_HOME}, which would be specific to tomcat.
This can easily be construed to work with other app servers as well (jetty/glassfish).
Other notes, on windows I was able to just define LOG_HOME as an
environment variable, where on linux I had to supply it via
CATALINA_OPTS.
I know the above isn’t rocket science, but perhaps we can make use of this generalization.