Archive for February, 2012

Unified logging in Oracle Fusion Middleware 11g


For some reason logging frameworks abound in the Java world. What is worse, many vendors have a hard time picking the right one and end up using several. Sometimes in the same product. Oracle Fusion Middleware is a case in point. It uses standard JUL (Java util logging) and ODL and optionally Log4j and/or commons logging and possibly other frameworks as well in dark corners. There is no single point of configuration and it is hard to add custom handlers/appenders. At least the situation is much better than in 10g.

What to do? Actually it is possible to route most logging to Log4j or JUL and to use a single configuration file for some of the settings. This makes it possible to add custom handlers/appenders in order to log to a database, to Nagios or to some other destination not supported out of the box.

There are many components in OFM 11g. This post focuses on SOA Suite, WLS and the Java node manager. Many of the other components can be handled similarly. It targets Log4j (which has a Nagios appender), but JUL would also work and would be a bit easier.

Node Manager

The node manager logging is not well documented, but it uses standard JUL. To make it use Log4j we can install the SLF4JBridgeHandler from slf4j – yet another logging framework. Edit the start script for the node manager and add the following jar files to the class path (along with any custom appender jars):


Add two properties:

where the Log4j properties (or XML) file is the one and only Log4j configuration file for the system and where contains:

handlers= org.slf4j.bridge.SLF4JBridgeHandler
.level= INFO
org.slf4j.bridge.SLF4JBridgeHandler= INFO

This redirects all log entries with level INFO or higher to Log4j. There is a performance penalty for using the bridge, but the node manager is not performance critical and is not affected much anyway as it logs relatively sparingly.

SOA Suite (and others)

Many of the applications in OFM use Oracle’s own logging framework ODL. For some reason they don’t share the same configuration, there are multiple ODL configuration files. Refer to the official documentation for details, this is covered. For SOA Suite the configuration file is found in soa_domain/config/fmwconfig/servers/server-name/logging.xml where server-name is the name of a managed server. In a HA installation all the servers must be configured.

ODL as such is pretty closed, it is evidently not meant to be extended by customers. However, it is built on JUL but with its own configuration (it doesn’t use LogManager). This means we can add JUL handlers.

Add the logging jar files listed above to the server’s class path, then edit logging.xml. Add:

<log_handler name="slf4j-bridge-handler" level="NOTIFICATION:1"/>

Add the new handler to the root level:

<handler name="slf4j-bridge-handler"/>


<logger name='' level='WARNING:1'>
<handler name='odl-handler'/>
<handler name='wls-domain'/>
<handler name='console-handler'/>
<handler name="slf4j-bridge-handler"/>

Unless the child loggers are configured differently all messages that are logged with level WARNING or higher will be sent to Log4j, as well as to the standard locations. As with the node manager, define log4j.configuration to point to the common Log4j configuration file.

A word of warning. While performance is a non-issue for the node manager, it can affect SOA Suite. Logging can be prolific and the bridge can make it much slower. The solution is to use the administration console and/or the ODL configuration file and set logging levels in ODL so that only messages that actually should be logged are sent to Log4j. The Log4j configuration can pick the proper appenders, but should not filter messages.


The final piece of the puzzle is WebLogic Server. According to the official documentation it can be configured to use Log4j, so everything should be fine. Right? No. Actually it can use handlers/appenders from JUL or Log4j or commons logging, but it will not use the configuration files from any of these frameworks. It is not possible to add a Nagios appender to the Log4j configuration and add it to WLS loggers. Standard but not so standard – why? Oh well, nothing we can’t solve with a few lines of well-placed code.

First configure the server to use Log4j following the official documentation. Point it to the common Log4j configuration file. Define a logger in the file with a reserved name (anything will do) and configure it with the appenders that should be used with WLS, for example JDBC and Nagios. Next, create a startup class and copy the appenders from the logger with the reserved name to the WLS server logger:

  public static void main(String[] args) {
    Logger serverLogger;

    try {
      serverLogger = Log4jLoggingHelper.getLog4jServerLogger();
    } catch (Exception e) {

    for (@SuppressWarnings("rawtypes")
      Enumeration appenderEnum = Logger.getLogger(LOGGER_WITH_APPENDERS)
      .getAllAppenders(); appenderEnum.hasMoreElements();) {
      serverLogger.addAppender((Appender) appenderEnum.nextElement());

Register the startup class in the administration console. Finally, at long last all the main components use the same Log4j configuration file (albeit not fully) and can log to custom appenders. A step towards unified logging, at least.

Beware of logging loops! WLS creates log entries for text written to standard out or error, so a console handler/appender will generate new log entries for every line it writes. Not a good idea, never log to the console.

Categories: SOA Suite

Proxy the proxy

Many corporations prevent direct Internet connections from the internal network, enforcing the use of a proxy server. That does not have to be an issue, but in Windows shops the proxy often requires Windows (NTLM) authentication. Few Java applications support that, there are even many native Windows applications that fail.

Want to upgrade Eclipse or jDeveloper or install a cool plugin? Not very convenient, everything must be downloaded and installed manually. Want to use Maven? Again, all dependencies must be downloaded and installed manually.

Enter Cntlm, a small and efficient proxy server that supports NTLM. Install it locally and use it as a go-between. Applications such as Eclipse can connect to Cntlm without authentication and Cntlm talks to the official proxy.

There is only one snag. Cntlm needs a user id and password, or at least a password hash. Be sure to stop or update Cntlm before changing your password, or you may be locked out!

Categories: Networking