The following sections describe how to use WebLogic logging services for your application logging:
WebLogic logging services provide information about server and application events. You can use WebLogic logging services to keep a record of which user invokes specific application components, to report error conditions, or to help debug your application before releasing it to a production environment. Your application can also use them to communicate its status and respond to specific events. See "Understanding WebLogic Logging Services" in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
Two features of WebLogic logging services from which your application can benefit are its extensibility and support for internationalization.
You can create your own catalog of log messages and use WebLogic utilities to generate Java classes that you can use in your application code. The log messages generated from your applications will be integrated with and treated in the same way as log messages generated by the server. See Chapter 5, "Writing Messages to the WebLogic Server Log."
Log message catalogs you create can be written in any language and can be accompanied by translations for different locales. WebLogic support for internationalization ensures that the log messages are present in the appropriate language for the current locale under which WebLogic Server is running. See Chapter 3, "Internationalization and Localization for WebLogic Server."
A major advantage of integrating your application logging with WebLogic logging framework is ease of management. The Administration Console lets you manage all of the log files and related options. See "View and configure logs" in the Oracle WebLogic Server Administration Console Help.
There are several ways to generate log messages from your applications and integrate them with WebLogic logging:
Use WebLogic tools to build custom log message catalogs and their associated Java APIs. Applications can invoke the log methods exposed by these interfaces to generate log messages. The message catalogs can be easily internationalized. See Chapter 4, "Using Message Catalogs with WebLogic Server."
Use the WebLogic non-catalog logger to generate log messages.
With NonCatalogLogger, instead of calling messages from a catalog, you place the message text directly in your application code. See Using the NonCatalogLogger APIs.
log() method available to servlets and JSPs in
javax.servlet.ServletContext. See Using ServletContext.
Application developers who do not use WebLogic message catalogs,
NonCatalogLogger, or servlet logging can do the following:
Use the Java Logging APIs to produce and distribute messages.
Use Log4J to produce messages and configure the server to use Log4J or the default, Java Logging, to distribute messages.
Use the Commons API to produce messages.
For more information, see org.apache.commons.logging at
Use the Server Logging Bridge handler (for Java Logging), or appender (for Log4J), which redirects application log messages to WebLogic logging services.
The WebLogic logging infrastructure supports a logger on each server that collects the log events generated by your own applications and subsystems. WebLogic Server provides direct access to the logger on each server, as well as to the domain logger on the Administration server.
By default, WebLogic logging services use an implementation based on the Java Logging APIs. The
LoggingHelper class provides access to the
java.util.logging.Logger object used for server logging. See the LoggingHelper Javadoc.
Alternatively, you can direct WebLogic logging services to use Log4j instead of Java Logging. When Log4j is enabled, you get a reference to the
org.apache.log4j.Logger that the server is using from the
weblogic.logging.log4j.Log4jLoggingHelper class. With a Log4j
Logger reference, you can attach you own custom appender (handler) to receive the log events or you can use the
Logger reference to issue log requests to WebLogic logging services. See the
In addition, WebLogic logging services provide an implementation of the Jakarta Commons
Log interface, so you can program to the Commons API and direct log messages to the server log file or any of the registered destinations. This API provides you with an abstraction that insulates you from the underlying logging implementation, which could be Log4j or Java Logging.
Applications that do not currently use WebLogic logging services can use the Server Logging Bridge. The Server Logging Bridge provides a lightweight means for applications to have their messages redirected to WebLogic logging services without reconfiguring the application or making any code changes, such as using the WebLogic Logging APIs.
The Server Logging Bridge is available as follows:
For applications that use Java Logging, the Server Logging Bridge is made available as a
java.util.logging.Handler object that can be specified in a
logging.properties file that is passed in an argument in the server's
weblogic.Server startup command.
For applications that use Log4J Logging, the Server Logging Bridge is made available as an
org.apache.log4j.Appender object, which can be specified in a
log4j.properties file that is included in the application classpath.
The logging properties file can also specify how the message severity level can be propagated to WebLogic logging services, as well as the specific destination to which messages should be published.
For more information, including examples, see the following sections in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server: