...

Requirements

 Java 5.0 - 8.0

Benefits

Not all components of a system under test communicate over a defined wire protocol or an API that can be virtualized by easily reconfiguring the application under test (AUT) to direct traffic to a different host or a different endpoint. In some cases, integration takes place via APIs that cannot be controlled without modifying the application code directly.

For teams working with Java AUTs, Parasoft's Java Virtualization agent can be used to record Java method calls directly within the application JVM and virtualize the behavior of these calls. The Parasoft Java Virtualization agent is particularly useful for virtualizing RMI, remote EJB calls, or any other internally-developed code that provides functionality and/or connectivity to a dependent system.

Methodology

The AUT is launched with the Parasoft agent configured as a JVM startup parameter. The configuration for that agent indicates whether it is in inactive, record, or virtualize mode for each of the specified target classes and methods.

...

Here is a sample PVA that was recorded on the Oracle WebLogic medrec sample application:

Java Virtualization Patterns

There are two distinct virtualization patterns that can be used to record Java method invocations and virtualize their return values:

...

The best pattern to apply depends on the application needs. You can mix the two virtualization patterns, as well as mix various modes for each of the specified classes/methods.

Class Method Virtualization

In this pattern, call callers of class V receive virtualized return values. Essentially, this globally alters the behavior of class V regardless of how (and from where) its virtualized methods get invoked.

To configure this type of virtualization, you provide the fully-qualified class name as well as the name of the methods that you want to virtualize (or record, when in record mode). The return values of these specified methods will be altered when in virtualize mode.

Call Virtualization

In this pattern, you virtualize how certain methods get invoked (or called) from specific places. Here, you provide:

• The fully qualified name of the calling class. This is the class where virtualization on method calls into some other classes and methods will be applied.
• The list of methods within the calling class from which virtualization is going to be applied. When these methods call specific other objects and methods (the items below), they will be get virtualized.
• The fully - qualified name of the class type that is going to be virtualized from within the calling class. This is the declaring interface or object type on which to apply the virtualization.
• The list of methods on which to apply the virtualization.

This pattern is particularly useful for remote EJB method invocation virtualization. The calling class would typically be a controller object. Within that object, remote EJB invocations are made using some declared remote interface type. Here is an illustration of how remote EJB calls can be virtualized using this pattern:

Agent Configuration

Configuring the Java Application to Use the Agent

1. Copy ParasoftJavaVirtAgent.jar and the other accompanying files to a file path location that can be accessed by your application.

2. Add the following JVM argument to your application’s “java” startup executable (provide as a single line with a space before each –D argument):

   Code Block
   language text
   -javaagent:"C:/PathTo/ParasoftJavaVirtAgent.jar" -Dparasoft.virtualize.config="C:/Path/AgentConfig.xml" -Dparasoft.virtualize.log.config="C:/Path/logging.properties"

...

Setting Xbootclasspath is necessary.

Configuring the Agent to be Controlled by a Virtual Asset

Deploy the JavaVirtualization.pva (included in the zip archive) to a Virtualize server and set the agent's Virtualize Server URLto point to that asset. This asset will then be able to:

...

To have the agent send recorded traffic to the Virtualize server, set the "recorderType" in AgentConfig.xml to "HTTP_TRAFFIC_SERVER" (see the following section for more details on AgentConfig.xml).

Configuring Agent Logging

The agent includes a logging.properties file, which can be edited in order to adjust the verbosity and location of the local log files that are created by the agent. Since the agent uses Java’s standard built-in logging framework, properties and settings that apply to that framework are applicable to the agent. (see http://docs.oracle.com/javase/7/docs/technotes/guides/logging/overview.html) In general, the following two properties should be considered:

...

[Parasoft Java Virtualization Agent: INFO {timestamp}] transforming {class name provided in the agent configuration XML}

Overview of AgentConfig.xml

AgentConfig.xml is an XML descriptor that is specific to the agent. It tells the agent which classes and methods to apply to—and in which mode (virtualize, record, etc.). Here is a sample configuration file:

...

As you can see from this example, it is possible to mix the two virtualization patterns and mix various modes for each of the specified classes/methods.

Generating the PVAs

Once the application is exercised with the desired scenarios and with some classes/methods configured with RECORD mode, the recorded file can be taken from the AUT and provided to Virtualize’s PVA creation wizard from traffic.

...

A responder will be created for each unique method because each recorded method will have a unique XML root element in the XML file. Each responder will be created in the "Multiple Responses" mode to reflect the various input arguments/return values that were recorded.

Using the Generated PVAs

Once the PVA is deployed, switch AgentConfig.xml to VIRTUALIZE mode and point the url element at the PVA deployment HTTP endpoint. The agent will cause the application’s JVM to redirect the specified method calls remotely to Virtualize (over HTTP) instead of calling the actual methods. The return objects that are configured in Virtualize will be used as the return values for these methods.

Assumptions and Limitations

The Java virtualization agent is particularly useful for recording and virtualizing stateless method calls that perform some function in another subcomponent within the application or call out remotely into some dependency.

...

• Does not record object state.
• No per-instance controls –everything is at a class/object type level.
• Does not record/virtualize thrown exceptions.
• Calling method argument values do not impact virtualized returned values.
• Methods are identified by class name and method name; not yet with fully qualified signatures.
• Applications need to be restarted to apply mode changes.

Tutorial: ParaBank

Class Method Virtualization

First, let's try the Class Method Virtualization pattern by virtualizing the behavior of the ConfigurableLoanProvider class, which is invoked to request a loan regardless of what loan provider is configured in ParaBank.

1. Create the ParaBank project within Virtualize.
2. Use the AgentConfig.xml sample provided above (change localRecordingFilePath to the location where you wish to save the recording file in your environment).

3. Open the ParaBank Run Configuration and add the VM arguments (all on one line, with a space separating each –D argument):

   Code Block
   language text
   -javaagent:"C:\PATH\ParasoftJavaVirtAgent.jar" -Dparasoft.virtualize.config="C:\PATH\AgentConfig.xml" -Dparasoft.virtualize.log.config="C:\PATH\logging.properties"

4. Run the configuration, then exercise the application as follows:
   
   1. Log into ParaBank using john/demo.
   2. Click the Request Loan link.
   3. Request a loan with a 1000 principal and a 200 down payment.
   4. Request another 10000 loan with a 100 down payment.
5. Verify that a file was created in the location you provided in local RecordingFilePath.

6. Shutdown ParaBank.

7. Create a new PVA from traffic as follows:
   1. Select Traffic> Generate Fixed Messages, specify the location of the traffic file, then click Next. 
   2. Select Based on operation/type for message grouping, then click Next.
   3. During Message Grouping Review, disable the Autoconfig option to manually configure the request matching options in the following step, then click Next.
   4. During Request Matching, remove existing parameters, and add only the loanAmount and downPayment elements as the relevant parameters for the request body, then click Next.

   5. Specify a deployment endpoint that will match what you have in the AgentConfig.xml. In this case, use:

      /ParaBankJavaLoanRequest

      Code Block
      language text
      <virtualizeServer> <url>http://localhost:9080/ParaBankJavaLoanRequest</url> </virtualizeServer>

   6. Click Finish.
      The PVA will be created with a single responder in Multiple Responses mode. Only a single responder would be created because only one method was virtualized in this example.
      
8. Edit the responses by adding the following:  <loanProviderName>Parasoft Virtualize</loanProviderName> 

9. Switch the AgentConfig.xml mode to VIRTUALIZE by using:

   Code Block
   language text
   <methodVirtualizationClasses> <method> <className>com.parasoft.parabank.domain.logic.impl.ConfigurableLoanProvider</className> <methodName>requestLoan</methodName> <argumentTypes> <string></string> </argumentTypes> <mode>VIRTUALIZE</mode> </method> </methodVirtualizationClasses>

10. Run ParaBank again and request loans with the same amounts that were previously recorded. Notice how the Loan Provider label will display whatever you specified in the Virtualize responder. If you enable monitoring on the virtual asset within Virtualize, you will be able to see the requests and responses that are generated by ParaBank and received by Virtualize.

Call Virtualization

Next, let's try the Call Virtualization pattern. The goal of this exercise is to virtualize the following call line under BankManagerImpl.java, method requestLoan():

...