Oracle Diagnostics Logging (ODL) for application development

Logging is a very important aspect of application development as it offers run-time access to the behaviour and data of the application. It’s important for debugging purposes but also to investigate exception situations on production. The Java developer has a choice between logging frameworks but Log4J is probably the most used one. The usage is quite simple: grab a Logger, e.g. private static Logger log = Logger.getLogger(MyBean.class);, and then use that logger to log the actual message at the required level, log.debug(“This is a debug message”);. To print the logmessages, the Log4J is configured externally with a properties file that defines the location (e.g. console, file, database etc.) and the format of the logmessages. Other logging frameworks, like Java Util Logging, are used in a similar way. It’s actually a good practice to not use Log4J directly, but to use a wrapping or facade framework, that allows switching of the actual logging implementation itself. In the past that would have been Apache Commons Logging (ACL), but now SLF4J is commonly used because it doesn’t have the classloader issues of ACL and it provides some nice message formatting (and performance) features like log.debug(“{} says: This is a debug message”, user.getName());. By the way, the logging usage of Log4J is similar to SLF4J so you can easily switch by only replacing the imports statements.

This is all quite simple for the developer working in his IDE, but log management becomes more complicated for a deployed application. First of all, the configuration file must be loaded by the application server often on its classpath, e.g. by including it with the application or else by storing it at a specific location and configuration of the server. Maintainance is done by direct manual editing of the file. An important requirement is (easy) run-time adjustement of the configuration, especially changing the loglevel. Although possible with Log4J, this is not a trivial exercise. The same applies for access to the logfiles. With Log4J it’s easy to define your logfiles, but they are often not easily accessible.

It would be great if logging would be integrated with the application server and the management console and thus allow easy and understandable configuration by administrators and easy access to the logfiles. For weblogic this is available via the Oracle Diagnostic Loggings (ODL). Let’s have a look how we can leverage our logging and ‘connect it’ to ODL.

ODL is based on Java Util Logging (JUL), so you have to change the Log4J implementation for JUL which is easy when using a logging facade like SLF4J. Now that ODL can pick up your log messages, it’s time to configure the server. The configuration resides in the logging.xml file, that can be found at system11.1.1.3.37.56.60\DefaultDomain\config\fmwconfig\servers\DefaultServer (for the embedded WLS, but the standalone WLS has a similar location). You may edit this file by hand, but you can also use a console. Weblogic provides one but for the embedded Weblogic server this console is available via JDeveloper. The log view, normally located at in the bottom of JDeveloper has a small ‘actions’ drop down button at the right side that provides access to the log configuration.

This opens the log configurator:

This configurator contains two sections: The loggers and the Handlers. The loggers section defines all the loggers with their loglevel, comparable to the Log4J loggers. You can choose if you’d like to have them displayed as ODL level or as Java level. The handlers section defines the way the logging is handled, the format and the files, comparable to the Log4J appenders. You can easily add your own loggers to the list, manually or via a search option to select the right package or class. So it’s a good practice to use the fully qualified classname for your logger.

As the configurator actually edits the logging.xml file, you can edit it both with the server running or with the server off. The latter allows for persistent configuration, while in the former situation a transient mode is also available. By the way, the ODL configurator is dynamic and interacts with the server to detect already used loggers. It even picks up loggers inside loaded classes like Managed Beans. The configuration has immediate effect without restarting the server :-).

The loggers can be ‘connected’ to one or more handlers. In the console you cannot add a new handler, only select it. New handlers must be defined by direct editing of the xml. A few standard handlers are available, like a console and domain handler. The configuration is a bit trial and error since the documentation about types of handlers and the formatters is limited.

In addition to log configuration, JDeveloper (and the Weblogic console) also provides a log analyzer, available via the same action drop down or via the menu -> Tools -> Oracle Diagnostics Log Analyzer. This allows for easy searching of the logs. It provides some very neat features, especially the ‘Relate By Request’ option to gather all log messages from the same request.

With ODL logging becomes much more usable and accessible, both for the developers as well as for the administrators. This allows for a better use of logging for problem analysis and internal application management. Happy logging.

References:

• Oracle Diagnostics Logging Documentation
• SLF4J
• Thought on Java Logging and SLF4J