Using WLDF to trace the time taken by your methods

WLDF stands for WebLogic Diagnostic Framework.

It's shipped within WebLogic Server and allow three types of features to help you diagnose your application and/or server :

  • => Collected Metrics
  • => Watch & Notification
  • => Instrumentation

We're going to focus on the AOP feature, commonly known as "Instrumentation".

I assume you're familiar with AOP concepts.


Sample Application : presentation


Our application is composed of three classes, calling each other the following way :

Component1 -> Component2 -> Component3

Each call will be delayed by a pause, in order to be able to observe some concrete data later.




For instance, here's the code for Component1 :


package fr.mbutton.blog.wldf;

* @author mbutton
public class Component1 implements CallerInterface {
    public void call () {
        try {
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
        CallerInterface comp = new Component2();



Configuring WLDF


From the application point of view


The configuration is pretty easy. It is embodied in a file weblogic-diagnostics.xml, which resides in the META-INF directory.

(I have chosen application scope, but you may chose the server scope. This is discussed in the official documentation)




Here's the content of this file :


<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics"
    <name>Sample WLDF resource</name>
            <pointcut>execution( * fr.mbutton.blog.wldf.* call*(...));</pointcut>


Let's take a closer look to the tags :

  • => enabled : has obviously to be set to true :) for both instrumentation & monitor
  • => name : has to be unique
  • => action : the action that has to be performed. Can be one of the following :


  • => location-type : before / after / around
  • => pointcut : the kind of execution on which the AOP behavior has to be performed

For more information, as usual, take a look at the official documentation.


From the server point of view


You have to configure a DyeInjectionMonitor.

To do so, activate the instrumentation by creating a module, and activating the instrumentation like shown below :




You may configure the DyeInjectionMonitor by adding some "Dye Flag".




For instance, here I added the dye flag "ADDR1". Make sure the flag you've chosen appears in the authorized constants.


Deploy your application to the server.


You may encounter the following error while deploying from Workshop.




It comes from the fact the console in development mode does not use (in theory) the configuration management,

aka the "Lock & Edit" feature.

To fix that, use WLST to release the lock, like :




I know it's not cool, but sometimes that's just the way it is.

And if you're not familiar with WLST, it will be the perfect occasion :)

Once deployed, launch the class Component1.


Displaying the data with the WLDF console extension


Installing the console extension


The console extension has to be installed into your domain. A console extension is a single JAR file.

For the WLDF extension, it's shipped within the standard WLS distribution.

You will find it here : BEA_HOME \ wlserver_10.3 \ server \ lib \ console-ext \ diagnostics-console-extension.jar

Then copy it in the directory : DOMAIN_HOME \ console-ext

Restart your server and you should see a new tab :




Viewing the collected data


Click this new tab, and then go in the "Request" tab.

Choose the server on which you have the EAR deployed (if many)

If no data is visible, click reload and then refresh.

You should get something like :




If you chose a particular method call, you may see a more detailed view like :




Let's zoom the contextual window :




There you go : you have a powerful tool, right here with no extra product ! :)

Hope it gave you a good example of the AOP use of WLDF.

If you want more info about WLDF, take a look at the page :



Have fun !




Alex said...

WLDF instrumentation does not rely on AspectJ although a large influence came from AspectJ work we did at BEA.
The instrumentation is tailored to be very fast and lightweight, and the pointcut are limited so that you can't shoot in your feet.
The actions (advice) are also limited to what is bundled by WLS - same here - so that you can't shoot in your feet (ie no action will change the control flow or threading).
Also WLDF since 10.3 (I think) support runtime class definition so you should be able to add actions and pointcuts at runtime.

If you want to go beyond the semantics limitations of WLDF you can certainly use AspectJ or SpringAOP in your apps.

Maxence Button said...

:) you're right Alex !
That's the price I have to pay for writing articles in the train or in the hotel : I may be "slightly" mistaken sometimes.

I will update the article according to your remarks.

Thanks buddy !