Got around to writing the deployment scripts that go with the Subversion work I did last week. As part of the scripts, I also worked on the problem I wrote about a couple weeks ago (ie: needing different log4j properties files per environment). Once you have a source control solution and a master build file, it’s pretty easy. I stripped out the explicit log4j category and appender directives and instead used the Ant <propertyfile> tag to write out the appropriate category / appender directives based on the presence (or lack thereof) of the project.debug property in my build file. When I want to create a build that outputs logging information to the console, this block of code is fired:
<target name="build.resources.debug" if="project.debug">
  <propertyfile
    file="WEB-INF/classes/log4j.properties">
    <entry key="log4j.rootCategory" value="INFO, STDOUT"/>
  </propertyfile>
</target>

Otherwise, this block is run:
<target name="build.resources.production" unless="project.debug">
  <propertyfile
    file="WEB-INF/classes/log4j.properties">
    <entry key="log4j.rootCategory" value="ERROR, SMTPAPPENDER"/>
    <entry key="log4j.category.com.mycompany" value="ERROR, SMTPAPPENDER"/>
  </propertyfile>
</target>

In Eclipse, you can easily create the project.debug property using the Arguments text box provided in Run –> External Tools –> $your ant build –> Main Tab –> Arguments: -Dproject.debug=true. By default then, log4j will only log error conditions and will send them to the SMTP appender.

The second thing I did was to create a deployment Ant script that wrapped my main build.xml. It checks out the source code from Subversion:
<exec executable="svn">
  <arg line="co svn://sourcecodeserver/myproject/branches/v1.0 . --username username --password password"/>
</exec>
, runs the normal build:
<ant antfile="build.xml" />
, stops the Tomcat service:
<exec executable="net">
  <arg line='stop "Apache Tomcat"'/>
</exec>
, deletes the existing web application from the Tomcat webapps directory:
<delete dir="${tomcat.install}myapp"/>
, creates and unpacks the generated war to the Tomcat webapps directory:
<mkdir dir="${tomcat.install}myapp"/>
<unzip src="myapp.war" dest="${tomcat.install}myapp"/>
and then starts the Tomcat service:
<exec executable="net">
  <arg line='start "Apache Tomcat"'/>
</exec>

We’ll see how well it works once this goes into production. If nothing else, at least I’ll have a couple more hours in my day.