public class Log4jFactory
extends java.lang.Object
| Modifier and Type | Field and Description |
|---|---|
static java.lang.String |
LASER_LOGGER_NAME_PREFIX
Laser alarm system logger name base.
|
| Constructor and Description |
|---|
Log4jFactory() |
| Modifier and Type | Method and Description |
|---|---|
static void |
enableAcsLogging()
This method must be called once in order to enable ACS logging behind the scenes of log4j logging.
|
Logger |
makeNewLoggerInstance(java.lang.String name) |
public static final java.lang.String LASER_LOGGER_NAME_PREFIX
public static void enableAcsLogging()
The log4j framework is quite resistant against being substituted with a different logging framework.
Even though it is possible to configure a custom logger factory using log4j.loggerFactory,
that factory will not be used when 3rd party code calls the usual Logger.getLogger(name).
It seems to make sense only for cases where the custom logger is used as in MyLogger.getLogger(name).
log4j-over-slf4j (http://www.slf4j.org/legacy.html) simply re-implements the relevant log4j classes,
which is too much trouble here for us because only basic log4j features are being used.
We make use of the RepositorySelector mechanism, which log4j foresees for a different purpose, to separate logging contexts in an application server that does not have classloader separation. (See also http://articles.qos.ch/sc.html.) It is not possible to configure this externally, so that an application must call this method. See also http://mail-archives.apache.org/mod_mbox/logging-log4j-user/200904.mbox/%3Ca44e15a30904020424g4b7d7fcx63ca32152c81f80d@mail.gmail.com%3E
public Logger makeNewLoggerInstance(java.lang.String name)