![]() |
![]() |
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 as log4j itself is implemented in terms of the UGLI interface.
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 parametized 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 to use just one implementation, that is NOP, Simple, JDK 1.4 logging and log4j, respectively.
Authors of widely-distributed components and librarires 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 and relatively robust approach avoids many of the painful bugs associated with dynamic discovery processes based on fragile classloader hacks.
Small applications where configuing log4j can be somewhat of an overkill can drop in ugli-simple.jar in place of log4j.jar.
Advantage | Description |
---|---|
Swappable logging API implementations | The desired logging API can be plugged in at deployment time by insterting the appropriate jar file on the classpath. |
Adapter implementations for the most popular APIs | UGLI already supports the most popular logging APIs, namely log4j, JDK 1.4 logging, Simple logging and NOP. |
Support for parameterized log messages | UGLI adapters, for all APIs and not just log4j, support parametrized log messages. |
Built-in support | Log4j has built-in support for UGLI. Actually, log4j
internally makes extensive use of UGLI. The
Logger class in log4j directly implements
UGLI's ULogger interface. Moreover, all log4j
components fallback on SimpleLogger
implementation for log messages genereted internally by
log4j in case of incorrect configuration.
|
Simplicity |
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. Just as importantly, UGLI does not rely on any classloader tricks. Every variant of ugli-<impl>.jar is hardwired to use one specific implementation. |
Ease of implemenation | The simplicity of the UGLI interfaces and the deployment model make it easy for developers of other logging APIs to easily conform to the UGLI model. |
No dynamic discovery | Life is too short to deal with classloader hacks. |