@Deprecated
Deprecated. as of Spring 4.2.1, in favor of Apache Log4j 2 (following Apache‘s EOL declaration for log4j 1.x)
Convenience class that performs custom log4j initialization for web environments, allowing for log file paths within the web application, with the option to perform automatic refresh checks (for runtime changes in logging configuration).
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):
•"log4jConfigLocation":
Location of the log4j config file; either a "classpath:" location (e.g. "classpath:myLog4j.properties"), an absolute file URL (e.g. "file:C:/log4j.properties), or a plain path relative to the web application root directory (e.g. "/WEB-INF/log4j.properties"). If not specified, default log4j initialization will apply ("log4j.properties" or "log4j.xml" in the class path; see the log4j documentation for details).
•"log4jRefreshInterval":
Interval between config file refresh checks, in milliseconds. If not specified, no refresh checks will happen, which avoids starting log4j‘s watchdog thread.
•"log4jExposeWebAppRoot":
Whether the web app root system property should be exposed, allowing for log file paths relative to the web application root directory. Default is "true"; specify "false" to suppress expose of the web app root system property. See below for details on how to use this system property in log file locations.
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.