|
|
|
The Universal and Generic Logging Interface or UGLI is intended to serve as a simple abstraction of various logging APIs allowing to plug in the desired implementation at deployment time. Note that log4j version 1.3 and later support UGLI directly. Log4j is implemented in terms of the UGLI interfaces.
1: import org.apache.ugli.ULogger;
2: import org.apache.ugli.LoggerFactory;
3:
4: public class Wombat {
5:
6: final ULogger logger = LoggerFactory.getLogger(Wombat.class);
7: Integer t;
8: Integer oldT;
9:
10: public void setTemperature(Integer temparature) {
11:
12: oldT = t;
13: t = temperature;
14:
15: logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
16:
17: if(temperature.intValue() > 50) {
18: logger.info("Temperature has risen above 50 degrees".);
19: }
20: }
21: }
The example above illustrates the typical usage pattern for UGLI. Note the use of parameterized log messages on line 15. See the question "What is the fastest way of (not) logging?" in the log4j FAQ for more details.
UGLI currently supports four implementations, namely, NOP, Simple, JDK 1.4 logging and log4j. Log4j 1.3 ships with four jar files ugli-nop.jar, ugli-simple.jar, ugli-jdk14.jar and log4j.jar. Each of these jar files are hardwired at compile-time to use just one implementation, that is NOP, Simple, JDK 1.4 logging and log4j, respectively.
Small applications where configuring log4j can be somewhat of an overkill can drop in ugli-simple.jar in place of log4j.jar.
Authors of widely-distributed components and libraries may code against the UGLI interface in order to avoid imposing an logging API implementation on the end-user. At deployment time, the end-user may choose the desired logging API implementation by inserting the corresponding jar file in her classpath. This stupid, simple but robust approach avoids many of the painful bugs associated with dynamic discovery processes. Life is too short to be spending it hunting down class loader problems.
The UGLI interfaces and their various adapters are extremely simple. Most developers familiar with the Java language should be able to read and fully understand the code in less than one hour.
As noted earlier, UGLI does not rely on any classloader tricks. Every variant of ugli-<impl>.jar is statically hardwired (at compile time) to use one specific implementation. Thus, UGLI suffers none of the class loader problems observed when using JCL.
We hope that simplicity of the UGLI interfaces and the deployment model will make it easy for developers of other logging APIs to conform to the UGLI model.
The Logger class in log4j directly implements
UGLI's ULogger interface. Moreover, log4j makes
extensive use of UGLI internally.
Log4j's built-in support for UGLI means that the adapter
for log4j does not need to wrap log4j objects in order to make
them conform to UGLI's ULogger interface. A log4j
Logger is a ULogger. Thus,
using UGLI in conjunction with log4j involves strictly zero
memory overhead and near-zero computational overhead. The
computational overhead is so small as to be unobservable.
UGLI ships with log4j version 1.3alpha-6 and later.
| Advantage | Description |
|---|---|
| Fail-safe operation | Assuming the appropriate jar file is available on the
classpath, under no circumstances will UGLI cause your
application to fail. This is because no UGLI class loaded
in memory will ever throw an exception.
Contrast this with
|
| Swappable logging API implementations | The desired logging API can be plugged in at deployment time by inserting the appropriate jar file on the classpath. |
| Adapter implementations for the most popular APIs | UGLI supports the most popular logging APIs, namely log4j, JDK 1.4 logging, Simple logging and NOP. |
| Support for parameterized log messages | All UGLI adapters support parameterized log messages. |
| Built-in support in log4j | Log4j's built-in support for UGLI directly translates into smaller memory footprint and better CPU efficiency. |