The current mechanism of obtaining log4j.config and the logs filepath is not
diplomatically correct for deployment in J2EE app servers. Yes, it will work,
however it forces ALL WEB APPLICATIONS *plus* the Application Server itself
to share the same configuration information. This is bad citizenship.
Each web application should load its own log4j classes and gets its own
1. Consider using a startup-servlet in TC to bootstrap the log4j subsystem.
This is covered in http://logging.apache.org/log4j/1.2/manual.html under the Section
marked "Initialization Servlet". As an initial step you could hardcode the name
"teamcity-server-log4j.xml". Now, the deployed, can place that file in the SHARED
classpath directory of the app server (i.e. $TOMCAT/common/lib, $JBOSS/common/lib).
Or, if they so choose, they can specifically tweak the deployment descriptors such that only
the TeamCity context can read that file.
2. Dont use -Dproperty=value to configure application-specific parameters, as these are shared
by ALL webapps AND the appserver. Use JNDI instead. It's rather easy! Declared in TeamCity's
context.xml the <resource-env-ref> elements injected by the container. Use your startup servlet to
retrieve the values of the properties from JNDI (InitialContext, lookup() etc), then store those configurable
properties on a singleton somwhere for TeamCity. The deployer can then simply and cleanly place
the configurable properties on their app server ; for instance, in Tomcat in server.xml or using the Admin Tool,
or for WebSphere/JBoss/etc - in the JNDI parameter registry.
3. Consider using JNDI database resources. Again, this is covered in the Tomcat HowTo's as an simple
example and the practice is well established for any folks writing J5EE apps.