Browse Prior Art Database

Common Logging Framework Disclosure Number: IPCOM000129263D
Original Publication Date: 2005-Oct-04
Included in the Prior Art Database: 2005-Oct-04

Publishing Venue



A common requirement during application development is the inclusion of message and trace logging output. However, the addition of logging code into an application leads to an undesirable coupling between the logging implementation used and the application itself. To address these needs, a logging framework into which various logging engines may be seamlessly integrated is required. The Common Logging Framework has been designed to achieve this goal.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 24% of the total text.

Page 1 of 10

Common Logging Framework

The Common Logging Framework, or CLF, consists of an application level logging API, the Java Standard Edition Logging API as defined by JSR 47; and a logging engine API, or "runtime facility". The runtime facility implementation is specified at runtime. This allows logging to be integrated into an application without binding the application to any particular logging engine. Clearly, such a framework is important in maintaining a loose coupling between an application and the logging runtime.

The use of the JSR47 logging API by the Common Logging Framework allows applications to be written using a consistent, standards based logging API. The runtime facility API allows any logging engine to be integrated seamlessly into the framework at runtime. In this manner, the application is shielded from proprietary logging APIs and may integrate with different logging engines without code changes.

The Common Logging Framework is outlined by the following UML diagram:


Page 2 of 10


[This page contains 1 picture or other non-text object]

Page 3 of 10

The core class, <<>> extends the Java Standard Edition class <<java.util.logging.Logger>> using the Decorator design pattern. This allows the CLF API to be consistent with the industry standard java runtime logging API. Applications using the CLF may obtain an instance via the factory methods <<>>.getLogger(String) and <<>>.getLogger(String, String), in the same manner they are obtained from the Java factory method calls.

The "runtime facility" API of the CLF, as defined by the interface <<>>, is implemented by any logging engine that wishes to be plugged into the framework. Plugins have been developed for several logging engines as well as the Java Standard Edition platform itself. The presence of a Java runtime plugin allows the CLF to integrate seamlessly with the standard logging engine provided by the Java runtime. This flexibility is crucial for applications that are required to operate in diverse runtime environments.

The runtime facility implementation is integrated into the framework as an attribute of the <<>> instance. When a Logger is requested from the framework, an instance of the configured runtime facility is created and initialized by the framework, wrapped within the Logger, and returned to the caller. Since the Logger object returned decorates an instance of <<java.util.logging.Logger>> and contains an instance of <<>>, requests on the Logger object may thus be dispatched to the runtime seamlessly. In addition, this design allows changes in the underlying runtime facility configuration to be reflected correctly back to applications using the Logger instance. The runtime facility to be used by the framework is specified via a properties file.

Type documentation is p...