| 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" in the class path; see 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.
author:
Juergen Hoeller
since:
12.08.2003
See Also: org.springframework.util.Log4jConfigurer
See Also: Log4jConfigListener
See Also: Log4jConfigServlet |
