RollingFileAppender file location

The log4j RollingFileAppender is a very useful appender. It maintains files according to the size of the log file, rolling them over as necessary. One of the parameters necessary to configure the RollingFileAppender is a filename - but where is this file located? Obviously, if an absolute pathname is used in the properties file, then that pathname is used for the file. But what about a relative path, especially where a web application is concerned?

Good web containers provide a way to configure relative file access. GlassFish and Tomcat provide this capability by making a property available. GlassFish uses as.home, Tomcat uses catalina.home.

GlassFish

log4j.appender.trace=org.apache.log4j.RollingFileAppender
log4j.appender.trace.layout=org.apache.log4j.TTCCLayout
log4j.appender.trace.File=${as.home}/webapps/slamd/WEB-INF/slamd.trace.log
log4j.appender.trace.MaxFileSize=1MB
log4j.appender.trace.MaxBackupIndex=1
log4j.appender.trace.layout.DateFormat=ISO8601

Tomcat

log4j.appender.trace=org.apache.log4j.RollingFileAppender
log4j.appender.trace.layout=org.apache.log4j.TTCCLayout
log4j.appender.trace.File=${catalina.home}/webapps/slamd/WEB-INF/slamd.trace.log
log4j.appender.trace.MaxFileSize=1MB
log4j.appender.trace.MaxBackupIndex=1
log4j.appender.trace.layout.DateFormat=ISO8601

About SLAMD

The SLAMD Distributed Load Generation Engine (SLAMD) is a Java-based application designed for stress testing and performance analysis of network-based applications. Initial development of SLAMD was performed at Sun Microsystems, with recent development sponsored primarily by UnboundID Corp. Recent development work is by Terry Gardner and Neil Wilson.

SLAMD is available under the terms of the Sun Public License, which is an OSI-approved open source license. The main site for obtaining information about SLAMD is available at its home page, and it is available as a java.net project.

SLAMD was originally developed for the purpose of benchmarking and analyzing the performance of LDAP directory servers, and it is the most powerful and flexible tool available for this task. However, it is also well-suited for testing other kinds of network applications and has been used for things like Web servers and Web-based applications, relational databases, and mail servers. It can also be used for non-network based applications (and in fact, it is used for comparing things like CPU power and memory latency across a number of different kinds of systems), although its distributed nature makes it ideal for systems that can be accessed remotely.

SLAMD provides a Java-based API to make it possible to quickly develop custom workloads, and it also contains an embedded scripting engine that can make it easy to stress applications using protocols like LDAP, HTTP, SMTP, IMAP, and POP, or any database that can be accessed via JDBC. It also includes tools for recording and playing back TCP traffic, and a utility for intercepting LDAP communication and writing it as a script that may be executed in the SLAMD scripting engine.

SLAMD2 is being converted to use a web framework, in this case Struts. This involves separating the HTML generation from the database access code, in short, conversion to MVC. It is a big task, but a fun one. When complete, SLAMD - tentatively called SLAMD3 since I am not very imaginative - will have its display (view) completely separate from the model and the controller. The virtues of this are profound: easy to change the view without mucking about in the database code, easy to localize (only Southern United States English so far, but a Klingon locale is coming), easy to change the model without affecting the view and vice-versa, and a host of other benefits.

Posted at 03:34AM Apr 09, 2009 by tgardner in slamd  |  Comments[0]