Let's put Java VisualVM to some practical use. We'll take the simple Spring Rich Client demo that is distributed with the Spring Rich Client distro, spruce it up with JMX-aware tags and annotations, and then monitor one of its beans from within Java VisualVM.

 

Note: When it comes to Spring and JMX, chapter 20: JMX from the online Spring documentation cannot be recommended highly enough. Everything that follows below assumes you've read and understood that chapter.

 

We begin by configuring our instance of the Spring MBeanExporter class, where we declare our "Contact" domain object as a JMX Bean and inject some initial values for two of the domain attributes:

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
    <property name="beans">
        <map>
            <entry key="bean:name=customerBean" value-ref="customerBean"/>
        </map>
    </property>
</bean>

<bean id="customerBean" class="domain.Contact">
    <property name="firstName" value="Harry"/>
    <property name="lastName" value="Potter"/>
</bean>

 

Next, we simply need to annotate our "Contact" domain object:

...
...
...
@ManagedResource(objectName = "app.SimpleApp:type=SpringDemo", description = "Simple Example")
public class Contact {
...
...
...

 

Then run the application while Java VisualVM is running, with its MBeans plugin installed. Open the tab for the application and then look in the MBeans tab. You should see the following:

 

We've exposed all the attributes of our domain object. Let's not do that. First read section 20.3 of the abovementioned reference chapter. Then, to limit the attributes exposed to the JMX server, let's give ourselves some control over our MBean:

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
    <property name="namingStrategy" ref="namingStrategy"/>
    <property name="assembler" ref="assembler"/>
    <property name="beans">
        <map>
            <entry key="bean:name=customerBean" value-ref="customerBean"/>
        </map>
    </property>
</bean>

<bean id="customerBean" class="domain.Contact">
    <property name="firstName" value="Harry"/>
    <property name="lastName" value="Potter"/>
</bean>

<bean id="attributeSource" class="org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource"/>

<bean id="assembler" class="org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler">
    <property name="attributeSource" ref="attributeSource"/>
</bean>

<bean id="namingStrategy" class="org.springframework.jmx.export.naming.MetadataNamingStrategy">
    <property name="attributeSource" ref="attributeSource"/>
</bean>

 

Now we can be specific about which attributes to expose. In the "Contact" domain object, annotate the two methods that get the first name and last name:

@ManagedAttribute()
public String getFirstName() {
    return firstName;
}


@ManagedAttribute()
public String getLastName() {
    return lastName;
}

 

Note: Section 20.3.2 of the aforementioned reference document gives some interesting info here: "You will also notice that both the age and name properties are annotated with the ManagedAttribute attribute, but in the case of the age property, only the getter is marked. This will cause both of these properties to be included in the management interface as attributes, but the age attribute will be read-only." In other words, if you also annote the setters, then the attributes will be writable in Java VisualVM. Also read the document about Notifications (section 20.7), which could also be implemented in the context of Spring Rich Clients.

Run the application again and Java VisualVM will be more discriminating about the data it exposes:

Had you also annotated one or both of the setters, the font of the attribute would have been blue in Java VisualVM and you would have been able to edit its value:

However, VisualVM hasn't really proved its value thus far. We could simply have used JConsole instead. So, let's now create a VisualVM plugin specifically for our Spring Rich Client application. Once we've installed the plugin into VisualVM, we'll have created functionality specifically for our application so that we'll be able to monitor it visually in an easy and intuitive way from then onwards:

In fact, we won't even need the MBeans plugin anymore. Below, you see that there is no MBeans tab, although the JMX attributes are exposed in the explorer view:

As you can see, we'll let Java VisualVM recognize our Spring demo application as being different to all other applications. A special icon and display name will appear in the explorer view whenever the Spring demo starts up. Also, its attributes will be exposed in the explorer view so that we can immediately see them.

The next section will explain how simple it is to create a plugin that provides the above functionality. But how useful is it really? Well, you could extend it even further and, instead of the attribute name and type, also show the current value, which could be particularly useful in visualizing the application that you're monitoring:

 

Creating a VisualVM Plugin for the Simple Spring Demo

In this section, we'll create a plugin that modifies VisualVM in such a way that it will recognize our Spring demo application.

The way in which VisualVM recognizes an application is via its main class.

When VisualVM is running and an application starts up with the main class specified by our plugin, VisualVM will provide an icon and a display name specifically for our application, together with subnodes for each of the attributes we've made available via our Spring-driven JMX bean.

We'll start all of this via a template that is part of the VisualVM Sample Collection 1.0. So go to the sample collection's page, download it, and install it into NetBeans IDE 6.1.

1. Open the New Project wizard in the IDE and choose the "Explorer Subnodes" sample, which we'll use as our template:

   

 

2. Once you've completed the wizard, you'll have a project with error messages because you haven't set the plugin's platform. The platform provides all the modules that provide the APIs used by the plugin. Now that VisualVM is part of the JDK, it's simple to get the necessary platform:

   

    

3. Now that you've registered your platform, set VisualVM as the platform for the plugin you're working on:

   

    

4. Now we're going to perform some small tweaks that will customize the template to our needs. After all, instead of the Anagram Game application, for which it was made, it should now be tailored to work with the Spring demo application. Optionally, you could refactor all the class names so that "Anagram" isn't referred to anymore. But let's do the essentials only:

    

   • Open org.visualvm.demoapplicationtype.applicationtype.AnagramApplicationTypeFactory. In this class the "createApplicationTypeFor" method specifies which application will be handled by our plugin. That, in turn, is determined by the main class of the application, which in our case is "app.SimpleApp" (assuming you're working with the Spring demo that comes with the Spring RCP Tooling plugin from the NetBeans Plugin Portal). So change that method and ensure that the application's main class is referred to in line 3 below:

     @Override
     public ApplicationType createApplicationTypeFor(Application app, Jvm jvm, String mainClass) {
         if ("app.SimpleApp".equals(mainClass)) {
             return new AnagramApplicationType(app.getPid());
         }
         return null;
     }

      

   • Open org.visualvm.demoapplicationtype.application.AnagramApplicationProvider. Here is where JMX-related information is set. In "DiscoveryTask.onSchedule", make sure the same object name as the object name you defined earlier in the "Contact" domain object is used, for connecting to the JMX server:

     ObjectName obj = new ObjectName("app.SimpleApp:type=SpringDemo");

    

   • Open org.visualvm.demoapplicationtype.applicationtype.AnagramApplicationType. In the "getName()" method, change the display name to "Spring Simple Demo" (or whatever you'd like to have displayed in the explorer view). That's also where you can change the icon, using the "getIcon" method.

    

5. Install the plugin and run the Spring demo application. The application should now be recognized as being a distinct application, because the display name and icon should change to the values you specified above. If you install the MBeans plugin into VisualVM, you'll be able to view the JMX info. Whether you do so or not, you're able to expand the "Attributes" node in the explorer view and thereby see the attributes exposed by the application via JMX:

   

 

That's it. Without having needed to understand much about the source code, we've been able to adapt it in such a way that we now have a plugin that provides unique functionality for the Spring demo application.

 

Further reading:

• Chapter 20: JMX
  
• 5 Minute Guide to Spring and JMX
• Enterprise Management with Spring and JMX (PDF)
• Getting Started Extending VisualVM
• VisualVM's JMX API entrypoints available in VisualVM-Tools module