FAQ #33 - How to configure ADF diagnostics logging in WLS, Pt. 3

Introduction

In this third installment of posts related to the configuration of ADF diagnostics logging we will focus on the following topics: 1) how logs could be added programmatically to the diagnostics log, 2) how new Loggers could be added and configured to the diagnostics logging configuration and 3) how to dynamically configure the WebLogic diagnostics logging. This includes changing the logging levels for the configured loggers at run-time without the need to restart the server.


Main Theme

For some background information regarding diagnostics logging as it relates to ADF, JDeveloper and WebLogic refer to these earlier posts: FAQ #6 - How to fine tune ADF diagnostics logging in JDeveloper 11g R1  , FAQ #7 - How to configure ADF diagnostics logging in standalone WLS using JDeveloper 11g R1 and FAQ #8 - How to perform log analysis using the Diagnostic Log Analyzer in JDeveloper 11g . The main advantages of using Oracle Diagnostics Logging (ODL) when compared to other logging frameworks is its tight integration with WebLogic and JDeveloper. In WebLogic, the logs produced conform to and integrate with the diagnostics logging facility. Diagnostic logs include in addition to the message logged additional information such as the session and user that produced the log entry at run-time. This is essential when analyzing the logs. In JDeveloper the log configuration and analysis is integrated via the Oracle Diagnostics Logging Configuration and Oracle Diagnostics Log Analyzer respectively. Both are discussed in detail in the above referenced posts.

Programmatic Usage

Diagnostic logs can be generated programmatically from within your code by using the ADFLogger class. You simply instantiate an ADFLogger via the static createADFLogger() method and use its log() method. log() accepts a java.util.logging.Level parameter indicating the log level of the message that you are logging and it can be any of the ADFLogger.INTERNAL_ERROR, ADFLogger.ERROR, ADFLogger.WARNING, ADFLogger.NOTIFICATION and ADFLogger.TRACE. You can also use the severe(), warning(), info(), config(), fine(), finer() and finest() methods to do your logging. Here is an example:

// create the ADFLogger
private ADFLogger logger = ADFLogger.createADFLogger("package.class");
// log a trace
logger.log(ADFLogger.TRACE, "A trace log");


Configuration of Custom Loggers in JDeveloper

In the ADFLogger example above, "package.class" is a custom logger which is associated with the ADFLogger. You will need to configure this custom logger in the diagnostics logging configuration file logging.xml. Ensure that you load the appropriate logging.xml file for the WebLogic server you are configuring. The file can be found in the domain config\fmwconfig\servers directory for each server. So, open the appropriate logging.xml configuration file in JDeveloper and create a custom logger called "package.class" by clicking on the Add Logger icon as it shown below.

In the Add Persistent Logger dialog that is presented add the logger class specified above in the ADFLogger (i.e. package.class), set its logging level and click OK.

The custom logger will appear in the list of Loggers as it shown below. With its logging level set appropriately, your trace log in the earlier example will show in the diagnostics log.

Dynamic Configuration of Logging in WebLogic

Diagnostics logging can be configured dynamically in WebLogic via the wlst tool. Ensure that you run the wlst script located in the oracle common directory  - %MIDDLEWARE_HOME%\oracle_common\common\bin for a JDeveloper installation - and not the one under the WebLogic server home - %MIDDLEWARE_HOME%\wlserver_10.3\common\bin for the stand-alone WebLogic installed along with JDeveloper. The former provides custom commands for configuring diagnostics logging. First you will need to connect to the admin server via the connect() command as in connect('weblogic','weblogic1','t3://address:7001'). To change the logging level for the custom logger class above, use the setLogLevel() command as in setLogLevel(target="ManagedServer1", logger="package.class", level="ERROR"). Specify the target WebLogic server with the target= argument (ManagedServer1 in this example), the logger class with the logger= argument and the new logging level with the level= argument. It can be either a Java level or an ODL level. Some valid Java levels are: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, or FINEST. Valid ODL levels include a message type followed by a colon and a message level. The valid ODL message types are: INCIDENT_ERROR, ERROR, WARNING, NOTIFICATION, TRACE, and UNKNOWN. The message level is represented by an integer value that qualifies the message type. Possible values are from 1 (highest severity) through 32 (lowest severity). Additional commands for dynamic configuration of the diagnostics log will allow you to configure the Log Handler for each logger class, display the currently configured loggers and so on. For more details, check out the documentation references sited below.



Conclusion

If you are considering a logging framework for an application to be deployed on WebLogic, I suggest that you take a closer look at the Oracle Diagnostics Logging facility. Its tight integration with JDeveloper (logging configuration and log analysis) and WebLogic (diagnostics log format, dynamic configuration) makes it a comparable choice.

Until the next time, keep on JDeveloping!


References

Logging Custom WLST Commands
Using Custom WLST Commands

FAQ #32 - How to get started with JRockit Mission Control, Pt. 1

Introduction

JRockit Mission Control is a suite of tools that can be used to monitor, profile and manage the JRockit Java virtual machine. Among other, managing the JRockit Virtual Machine includes performing garbage collection on demand and eliminating memory leaks. JRockit is the virtual machine used in a production system by the WebLogic application server.


Main Theme

Installation of JRockit Mission Control

JRockit Mission Control must be installed on a client machine through which a target JRockit virtual machine running on a server machine can be monitored, profiled and managed. To download JRockit Mission Control, go to the JRockit Family Download page.

Accept the license agreement, select the appropriate version for your client operating system and proceed with the download. Once downloaded, start the installation by executing the file downloaded. Follow the installation wizard choosing in most cases the default options presented by the installer.

During the installation you will be given the option to install the JRockit JRE in the client machine. Select Yes (Install Public JRE) and click Next to proceed.

The installer will proceed with the installation of both the JRockit JRE and the JRockit Mission Control. Verify that the installation was successful and click Done.

Once installed, you can start the JRockit Mission Control by running the jrmc program in the target installation directory. When installed on a Microsoft Windows operating system a shortcut called Oracle JRockit Mission Control 4.0.1 is created under the Oracle JRockit JDK R28.1 for Java SE 6 with JRMC 4.0.1 (32-bit) group - for the version installed.

Before proceeding with Mission Control, you will have to configure the target JRockit Java virtual machine to allow its management via the Mission Control suite.


Configuration of target JRockit Java Virtual Machine

For the sake of this example, we will configure a WebLogic SOA deployment consisting of one administration server and two managed servers - one for SOA and another for BAM. Similar configuration steps can be taken to configure your own setup. Start by ensuring that your WebLogic is configured to run on the JRockit Java virtual machine. This should be the case in all production environments. To ensure that we are indeed using JRockit, we will manually set the JAVA_VENTOR parameter to Oracle in the setDomainEnv script.

We will also add a parameter called ENABLE_MNGMNT_CONSOLE in setDomainEnv to control whether JRockit is started to allow its management.

Thats all with the setDomainEnv script. We will proceed by adding a few lines in the startWebLogic script. Here we will check to see whether the management console is enabled and if it is we will check if the management console startup options are set. If there are none specified, we will specify some defaults. We will see below when configuring the managed servers that the management console start up options can be set in the startManagedWebLogic script. The lines that we will add to the startWebLogic script are:

As you can see in the above picture, we are starting the JRockit virtual machine with the -Xmanagement switch specifying no secure sockets, no authentication and 7091 as the default connection port. Each WebLogic server must be configured to allow Mission Control connections on a separate port.

We will conclude the configuration changes by adding the following lines to the startManagedWebLogic script:

What we have done here is configure a different JRockit management port for each managed server. In this case we need to make sure that the actual names of the managed servers are correct, so this needs to be adapted for your setup.

Now we can start the SOA domain. For each server, observe that the management options are set correctly.

Mission Control Connection Setup

Now that we have the target JRockit virtual machines configured to allow Mission Control management connections - remember that each WebLogic server runs on its own virtual machine, we can proceed by creating the connections to each virtual machine from within the Mission Control suite. To create a new connection, right-click on the Connectors node and select New Connection.

In the New Connection dialog specify the WebLogic server host name or IP address, the management connection port and the connection name. Click on the Test connection button to test the connection.

We will create a separate connection for each WebLogic administration and managed server configured for the SOA domain above. After creating all the connections the Mission Control suite should look like this:

To start a monitor session for each configured virtual machine, right-click on the appropriate connection  and select Start Console.

This will open a monitor console as it is shown below.

Additional monitor consoles can be opened by right-clicking on another connection and selecting Start Console. Each monitor session will be shown in a separate tab in Mission Control.

Conclusion

This concludes this first part of getting started with the JRockit Mission Control. In the next part we will look at some of the features of the Mission Control.

Until the next time, keep on JDeveloping!


Code

http://jdeveloperfaq.googlecode.com/files/JDeveloperFAQNo32.zip