Running JCoverage with WebSphere 4.0

The JProbe documentation provides general usage instructions for running JProbe with an application server. But their examples only use WebLogic. The following scenario demonstrates the use of JCoverage with WebSphere to provide code coverage info on the HitCount servlet.

Please send any corrections, omissions or other recommendations to pglezen@us.ibm.com.

Automatic or Manual Integration

Personally, I prefer the manual method for a different reason. With 4.0+ versions of WebSphere, and especially on Windows, integrating JProbe is easy. Hiding the details with an integration utility just leaves one in the dark when things go wrong. Activities such as code coverage analysis and application profiling are not typically undertaken by organizations in the application server evaluation stages. Normally the organization is close to or already in production with a J2EE application. For such an organization, a thorough understanding of how the application server and profiling tool interact is imperative.

That having been said, I'll use the integration tool in the first scenario and dump it in the trigger scenario to show you how to manage without it.

Getting Ready

1. JCoverage and WebSphere are installed.
2. WebSphere admin server is running and listening to port 900.
3. The "Default Server" is installed in Websphere but not running.

JProbe doesn't like application servers with spaces in the name. But "Default Server" is just such a beast. Fortunately, this is easy to change in the WebSphere admin console without screwing anything up. I just took the space out so that my default server is named "DefaultServer".

Automated Integration of JProbe and WebSphere

1. Start JCoverage. The WebSphere admin server should be running and listening on port 900; but you don't need the admin console. It's better not to run it at this point.

2. Create a new session - From the JCoverage session menu, select New Settings ....

3. Choose Application server - Choose the Using Application Server radial button and select IBM WebSphere 4.0 from the Application Server drop down list.

4. Get Integration ID - Click the More button to take you to the integration panel. IBM WebSphere 4.0 should be selected. Click Create to create a new ID. On the right hand panel, fill in your server directory (e.g. c:\WebSphere\AppServer). The JVM should be the one WebSphere uses.

   Any special JVM command line options can be entered using the Advanced button. When everything is set, click Save. The new entry should appear on the left hand panel as something like IBM WebSphere 4.0(1).

   Close the JProbe Application Server Integration window.

5. Enter Filters - Under Data Collection Settings there are two tables. In case the headings for these tables don't show, the first one is for filters, the second one is for triggers. In the first table, enter the names of the packages or classes you wish to be covered. These will usually be your servlet and EJB classes plus whatever helper classes you provide.

   In the case of this scenario, it is the HitCount servlet. Since HitCount is a member of the default package, you don't enter a package name. Just specify HitCount in the name field and Class for the code type. The Detail Level should be Include.

6. Check Boxes - Opt to Take Snapshot at Exit, Start Recording at Program Start and Ignore Abstract Methods. Don't select Report Only Method-level Coverage. Checking this disables the line-by-line granularity of the coverage.

7. View Runtime Data - Choose Do Not View Runtime Data. We are looking to automate this as much as possible. Real-time monitoring has it uses; but not many of them involve code coverage. It just slows everything down.

8. Snapshot Directory - Allocate a temporary directory solely for this purpose - something like c:\temp\jprobe\jcoverage. This should be used only for gathering traces, not for storing them. A different directory should be used for storing traces you wish to keep.

9. Save Settings File

10. Click Run - A lot of things are going on behind the scenes. JCoverage is first performing an XMLConfig export to save the current configuration of the admin respository. It then begins making a few changes. It adds a few environment and command line entries to the JVM. It will then start the WebSphere console for you.

11. Start Your Server - It should start up just like it did without JProbe.

12. Run your test case - Use the URL http://localhost/webapp/example/HitCount.Increment the servlet variable a few times. Then increment the EJB variable.

13. Stop the Server - This will result in the snapshot being generated in the temp directory you specified above.

14. Analyze Snapshot - From the JProbe Coverage console, load the snapshot and view the results.

Manual Integration of JProbe with WebSphere

In the next example, we will use JProbe triggers to produce a snapshot after each invocation of the servlet. We'll modify the application server attributes directly rather than using the integration tool. In doing so, we'll review the changes made to the application configuration by the integration tool. You'll see there aren't so many.

1. Start the JCoverage console and open the session.

2. Uncheck the boxes that begin coverage at program start-up and take a snapshot at exit.

3. Add a trigger for the service method of the HitCount servlet to resume on entry.

4. Add a trigger to pause on exit.

5. Add a trigger to snapshot on exit.

6. Add a trigger to clear on exit.

7. Save the settings.

8. Bring up the WebSphere admin console.

9. Go to the DefaultServer application server and choose the General tab. Click the Environment button. There should be two properties defined: Execute and Executable. Leave these alone for now. Cancel out of the Environment Editor.
10. Select the JVM Settings tab. Select Advanced JVM Settings. Among the command line arguments you should see the following:
    • -jp_input
    • -jp_java

    The -jp_input is probably set to some temporary file. Change it to the JPL file you saved to after you added triggers.

11. Start the DefaultServer.
12. Invoke the URL: http://localhost/webapp/examples/HitCount. With each "hit" you invoke, you should notice a snapshot appearing in your temporary directory. These are results of the triggers.

13. Shutdown the DefaultServer.
14. Now you can analyze the results.

Extracting JProbe from WebSphere

1. Start admin console.

2. Go to general of application server.

3. Click on Environment... box.

4. Set the EXECUTE property to NO. Be sure to click on Apply afterwards.

   The docs might say this is as far as you have to go. But if you get StaleObjectActivationException when you try to start your server, complete the next step.

5. Go to the JVM Settings tab of the application server. Click on Advanced JVM Settings.... Remove the -jp_input and -jp_java command line arguments. But write their values down so you can add them back again.

6. Click on Apply.

Your application server should now come up JProbe-free. To "slap it back on," just set the EXECUTE back to YES and set

1. -jp_java to your JVM
2. -jp_input to your JPL file.