Maintaining complicated legacy applications is a challenge, which is often made worse by lack of documentation, nonintuitive design, and coding practices. Unfortunately almost all software developers will find themselves with such an assignment at some point in their careers.

In the case of any application that utilizes a database, it is very useful to trace SQL statements generated by the application. Such a trace would help with profiling performance bottlenecks, debugging errors, and in facilitating the developer's understanding of the business processes associated with the application.

In the case of legacy applications we would want to do such tracing without changing any code or application configuration. I was able to use WebLogic's JMX API to quickly put together a little code to trace the JDBC calls of a very large and complicated legacy application without impacting the code and configuration of the application. In addition, this small project helped facilitate my understanding of JMX and how WebLogic uses JMX behind the scenes. In this article I will go over the details of using WebLogic JMX to trace SQL statements.

What is JMX?
JMX stands for Java Management Extensions. MBeans, or managed beans, are resources that can be managed through the JMX API. Most application servers use JMX to provide administration consoles and to manage resources. In addition, application developers can use JMX to provide administration and auditing capabilities in their custom applications.

What Advantages Does WebLogic's JMX Implementation Provide for Developers and Administrators?
WebLogic Servers use JMX MBeans for configuration and management. A WebLogic Server each has a copy of its own MBeans, which is updated by the administration server. The administration server maintains a master copy of the MBeans for all of the servers that it manages. If the administration server fails to come up, the managed servers can function based on their local copy of the MBeans until the administration server can become available to update the server's local MBeans.

Web Logic provides both an administration console, which does its work using JMX MBeans, as well as an API to allow application developers to configure and explore WebLogic resources. The easiest way to take advantage of WebLogic JMX is to use the WebLogic console to change the configuration of WebLogic resources and to view the metrics available in the console. While the monitoring and configuration capabilities of the WebLogic console are very powerful and will meet the needs of most applications running on WebLogic, the WebLogic JMX API provides an even more powerful instrument for managing applications running on the WebLogic platform. Using the WebLogic JMX API it is possible to configure and extend WebLogic resources and to also receive notifications from WebLogic's subsystems. For example, an application that is configured with n as the value for minimum and maximum number of JDBC connections might want to have a listener that listens to notifications from the WebLogic JMX MBeans and sends e-mail to an administrator in case the usage of the application crosses n-x concurrent JDBC connections, so that the administrator can decide on an increased value for n and reconfigure the JDBC connection pool(s) (where x is an arbitrary number that depends on the comfort level of the administrator). Examples of advanced uses of JMX by application developers include tracing events in the WebLogic subsystems, including EJB events and server start/stop events.

What Options Are Available for Profiling JDBC Statements in WebLogic Applications?
There are several techniques that can be used to create a dynamic trace of JDBC statements in a WebLogic application. Subclassing the Statement,PreparedStatement and CallableStatement classes from the java.sql package to print a trace using a logging system like Log4J or WebLogic logging and then using the subclasses in the application is a viable option, but it is not practical in the case of legacy code. Such traces may be available from tools such as TOAD, but such tools may not be easily available to application developers and may not provide all of the information that is required. AOP techniques are another valid choice for printing JDBC statements. However, at the time of writing AOP is not officially supported in WebLogic by BEA even though articles about WebLogic AOP have appeared on the dev2dev site. At the time of writing, getting AOP to work in WebLogic is not a trivial project. Using WebLogic JMX with WebLogic 6.1 and 8.1 does not require the use of any additional libraries or configuration, since all the required classes are available in weblogic.jar and the code is very simple to implement. In addition WebLogic JMX is a very mature technology and can be implemented without any changes to the core application code or bytecode.

Using the WebLogic JMX API
The WebLogic javadocs are available online at http://e-docs.bea.com/wls/docs81/javadocs/. The API contains several packages with management in their names. These packages are WebLogic's JMX implementation (see Table 1).

Using JMX to Trace JDBC Calls
A simple way to organize the tracing code and provide a UI to view the SQL is to write a JSP, a servlet, and a Java Bean or object. We'll go through the details of the bean/POJO here and leave most of the details of the UI/controller aspect out since most WebLogic developers already understand these very well. Note that you need not modify any deployment descriptors, database connection pools, or data sources in order to get the tracing to work. All changes to the needed application will happen at run time.

Step 1
First we'll create a class called MyTracerBean.java and import the WebLogic JMX packages and classes that we'll need.

import javax.naming.Context;
import weblogic.jndi.Environment;
import weblogic.management.MBeanHome;
import weblogic.management.configuration.JDBCConnectionPoolMBean;
import weblogic.management.runtime.JDBCStatementProfile;
import weblogic.management.runtime.JDBCConnectionPoolRuntimeMBean;
import javax.management.InstanceNotFoundException;
import javax.management.InvalidAttributeValueException;
import javax.naming.NamingException;

See Figure 1

These classes are in the weblogic.jar so you won't need to add any JARs or classes to the WebLogic classpath.

Step 2
Next we'll write a method to get the MBeanHome.

private MBeanHome getMBeanHome() {
//URL to the serve whose JDBC activity we are tracing
String url = "t3://localhost:7001";
    String username = "mywlconsoleuname";
    String password = "mywlconsolepsswd";
//The MBeanHome will allow us to
//retrieve the MBeans related to JDBC statement tracing
MBeanHome home = null;

try { //We'll need the environment so that we can //retrieve the initial context
    Environment env = new Environment();
    env.setProviderUrl(url);
    env.setSecurityPrincipal(username);
    env.setSecurityCredentials(password Context ctx = env.getInitialContext();
//Retrieving the MBeanHome interface for the server with //the url t3://localhost:7001
    home =(MBeanHome)ctx.lookup(MBeanHome.LOCAL_JNDI_NAME);
    } catch (NamingException ne) {
     System.out.println("Error getting MBeanHome " + ne);
    }
    return home;
}