public abstract class Log4jWebConfigurer extends Object
WARNING: Assumes an expanded WAR file, both for loading the configuration
file and for writing the log files. If you want to keep your WAR unexpanded or
don't need application-specific log files within the WAR directory, don't use
log4j setup within the application (thus, don't use Log4jConfigListener or
Log4jConfigServlet). Instead, use a global, VM-wide log4j setup (for example,
in JBoss) or JDK 1.4's java.util.logging
(which is global too).
Supports three init parameters at the servlet context level (that is, context-param entries in web.xml):
Note: initLogging
should be called before any other Spring activity
(when using log4j), for proper initialization before any Spring logging attempts.
Log4j's watchdog thread will asynchronously check whether the timestamp of the config file has changed, using the given interval between checks. A refresh interval of 1000 milliseconds (one second), which allows to do on-demand log level changes with immediate effect, is not unfeasible.
WARNING: Log4j's watchdog thread does not terminate until VM shutdown; in particular, it does not terminate on LogManager shutdown. Therefore, it is recommended to not use config file refreshing in a production J2EE environment; the watchdog thread would not stop on application shutdown there.
By default, this configurer automatically sets the web app root system property, for "${key}" substitutions within log file locations in the log4j config file, allowing for log file paths relative to the web application root directory. The default system property key is "webapp.root", to be used in a log4j config file like as follows:
log4j.appender.myfile.File=${webapp.root}/WEB-INF/demo.log
Alternatively, specify a unique context-param "webAppRootKey" per web application. For example, with "webAppRootKey = "demo.root":
log4j.appender.myfile.File=${demo.root}/WEB-INF/demo.log
WARNING: Some containers (like Tomcat) do not keep system properties separate per web app. You have to use unique "webAppRootKey" context-params per web app then, to avoid clashes. Other containers like Resin do isolate each web app's system properties: Here you can use the default key (i.e. no "webAppRootKey" context-param at all) without worrying.
Log4jConfigurer
,
Log4jConfigListener
Modifier and Type | Field and Description |
---|---|
static String |
CONFIG_LOCATION_PARAM
Parameter specifying the location of the log4j config file
|
static String |
EXPOSE_WEB_APP_ROOT_PARAM
Parameter specifying whether to expose the web app root system property
|
static String |
REFRESH_INTERVAL_PARAM
Parameter specifying the refresh interval for checking the log4j config file
|
Constructor and Description |
---|
Log4jWebConfigurer() |
Modifier and Type | Method and Description |
---|---|
static void |
initLogging(ServletContext servletContext)
Initialize log4j, including setting the web app root system property.
|
static void |
shutdownLogging(ServletContext servletContext)
Shut down log4j, properly releasing all file locks
and resetting the web app root system property.
|
public static final String CONFIG_LOCATION_PARAM
public static final String REFRESH_INTERVAL_PARAM
public static final String EXPOSE_WEB_APP_ROOT_PARAM
public static void initLogging(ServletContext servletContext)
servletContext
- the current ServletContextWebUtils.setWebAppRootSystemProperty(javax.servlet.ServletContext)
public static void shutdownLogging(ServletContext servletContext)
servletContext
- the current ServletContextWebUtils.removeWebAppRootSystemProperty(javax.servlet.ServletContext)