LoadRunner Java Environmental Requirements

Overview

When using LoadRunner Java Virtual Users, (be it RMI, Corba, or Template VUsers) you must ensure that the environment of the development machine is configured properly.

The most common mistake in the configuration of a machine lies in the setting of the system environmental variables “PATH” and “CLASSPATH.”

Here is why these two system environmental variables are so important:

PATH

The PATH setting lets your machine know where to look for files. Order matters in this list. Your machine will search in the order of the directories listed in the variable.

LoadRunner depends on this Environmental Variable to find the files related to the Java Development Kit, LoadRunner, Operating Systems, etc.

CLASSPATH

The CLASSPATH setting tells the Java setup on your machine know where to find files needed for the compilation and execution of code. Again, this Environmental Variable is sensitive to the order of entries in the list. This is especially important since there are certain LoadRunner files that must be loaded first; thus, LoadRunner classes directories should be listed first in the CLASSPATH Variable.

Installation Requirements

1. Install LoadRunner

It is preferable to use a path without spaces, for example:

C:\LR702 or C:\loadrunner

and not C:\Program Files\loadrunner.

2. Install the JDK

Please note that the full installation of Sun’s JDK should be installed. Do not install the JRE. The JRE is not sufficient for successful integration with LoadRunner.

The versions of Sun’s JDK should be greater or equal to JDK 1.1.8.

3. Install your RMI/Corba Application (Optional)

If you do have an RMI/Corba application (i.e., a Web-based application), install it. If not, do not worry.

System Configuration

1. It is preferable to install LoadRunner and JDK to a location use a path without spaces. It is preferable to use a path without spaces, for example:

C:\loadrunner or C:\JDK

and not C:\Program Files\loadrunner

2. Setup the System PATH:

a. Right mouse click on My Computer à Properties

b. On the ‘System Properties’ window:

i. Go to “Environment tab” for Windows NT platform

ii. Go to “Advance tab” à “Environment variables…” for Windows 2000 platform

c. Append LoadRunner and JDK to the path. The information should be entered in the following order:

i. \bin

ii. \bin

iii. \jre\bin\classic (** JDK 1.2.2 and above only)

iv. The rest of the PATH for your machine

EXAMPLE:

PATH=C:\JDK\bin;C:\LR702\bin;C:\JDK\jre\bin\classic

4. Click and close the System Properties Window.

3. Setup the System CLASSPATH:

a. Right mouse click on My Computer à Properties

b. On the ‘System Properties’ window:

i. Go to “Environment tab” for Windows NT platform

ii. Go to “Advance tab” à “Environment variables…” for Windows 2000 platform

c. Add LoadRunner and JDK to the CLASSPATH. The information should be entered in the following order:

i. \classes

ii. \classes\srv

iii. Any files needed for your Java application

iv. \jre\lib\rt.jar (** JDK 1.2.2 and above only)

v. \lib\classes.zip (** Lower than JDK 1.2.2 only)

EXAMPLE:

CLASSPATH=C:\LR702\classes;C:\LR702\classes\srv;C:\JDK\jre\lib\rt.jar

d. Click and close the System Properties Window.

How to verify your environment setup in LoadRunner

After setting up the machine as specified in the ‘System Configuration’ section, you should now be able to run a simple Java Virtual User in Virtual User Generator. Perform the following steps to verify the correct installation and configuration of your system.

1. Start the LoadRunner Virtual User Generator.

2. Go to File à New.

3. Select RMI-Java. You should see a Start Recording Dialog Box.

4. Click Cancel.

5. Go to Vuser à Run.

In the Execution Log, you should see:

Virtual User Script started

Starting action vuser_init.

Ending action vuser_init.

Running Vuser...

Starting iteration 1.

Starting action Actions.

Ending action Actions.

Ending iteration 1.

Ending Vuser...

Starting action vuser_end.

Ending action vuser_end.

There should not be any errors during the run. Being able to run a blank script shows that the system is setup and LoadRunner is able to make calls to the appropriate executables (PATH settings), as well as find the relevant class files (CLASSPATH settings).

Java Template Virtual User

Java template is a scripting solution. You will need to write up the script. You cannot record your application using this method.

Also, please make sure that all classes required by your code are listed in the CLASSPATH (part 3 of the CLASSPATH list above). If not, you will see “Class not found” errors in the Execution Log during run-time.

Tips and tricks

Record

How does the application launch? Is it a call to a batch file? Is it a double-click on a shortcut to the actual executable? Is it brought up via a browser? The way an application is launched may make quite a difference in the process of starting a LoadRunner Java recording.

When you record an application, you should see a Mercury Loader Window appear listing all the objects being loaded by LoadRunner. If you do not see this window, then there is an environmental issue with the machine.

When LoadRunner records, classes in the \classes and \classes\srv directories must be loaded first. Thus, the importance of the ordering in the PATH and CLASSPATH environmental variables.

Listed below are some examples of starting a recording. They are only examples and are not exhaustive.

Batch File Launch

If the application is normally launched via a batch file, please try the following:

1. Make a copy of the batch file. Call the copy “Start_Vugen.bat.”

2. Edit Start_Vugen.bat with a text editor (e.g., Notepad).

3. Understand what each line of the batch file does. Get help if necessary.

4. If there are lines in the file which modify the PATH and CLASSPATH prior to the launch of the application, modify the PATH and CLASSPATH variables such that they correspond to the format as listed above in the Configuration section.

5. There should be a line in the batch file that launches the application (e.g., java test –a1 –a2 –a3), comment this line out.

6. In the place of the line that launches the application, type in:

vugen

7. The Start_Vugen.bat batch file should now setup the environment and start the Virtual User Generator. Run the batch file and confirm that it launches VuGen.

8. Start a new RMI/Corba script. The Start Recording Dialog Box should appear.

9. Set the Application Type to Java Application.

10. Set the App. Main Class to the class listed in the batch file line that starts the application. For example, in step 5, the class is “test.”

11. Give the Working Directory of the application.

12. Set the App. Parameters to the arguments listed in the batch file line that starts the application. For example, in step 5, the arguments are “–a1 –a2 –a3.”

Browser

1. Set the Application Type to the Browser version you normally use to bring up the application.

2. Provide the URL.

Application

1. Set the Application Type to Executable/Batch.

2. Set the Executable/Batch to the executable which launches the application.

3. Set the Working Directory to the working directory of the application.

Additional Information:

1. The ‘Debug option’ in the “Recording Option’ has. To view these extra Java debug options, refer to Problem ID 11323 - Enabling the hidden debug options of the Java recorder

2. The Java-Protocols recorder uses a hooking mechanism to support known protocols, like: RMI, CORBA. For information on custom hooking, refer to Problem ID 11287 - How to do Java custom hooking

Replay

When replaying a script, you have to ensure that the environment is setup properly so that LoadRunner is able to find all the classes used by the application.

If you get a “Class not found” error during execution, please try the following:

1. Take the CLASSPATH listed in the recording log and enter it into the Additional CLASSPATH field in the Run-time Settings (Run-time Settings à Java VM).

2. Take any arguments used by the Java application and enter it into the Additional VM Parameters in the Run-time Settings (Run-time Settings à Java VM).

When you play a script on a Remote Load Generator machine, you must make sure that the class files exist on that machine itself. The easiest way to ensure this is to install the application on the machine. Make sure you setup the Load Generator Machine exactly like the machine you used to record the application.

Additional Information:

1. Replay of Java Vuser is not supported on UNIX or Linux platform.

2. If you are running the Vusers as a process, then there will be one JVM for each Vuser. If they are running as threads, there will be as many Vusers to a JVM as there are threads to the process. You can also verify this information from the number of ‘mdrv.exe’ running on the machine.

Problem Description: Unable to run a Java Template script as a thread

The Java Template script works fine when running it as a process. When running it as a thread, the user receives the following exception:

"jndiFactory=weblogic.jndi.WLInitialContextFactory [MsgId: MMSG-17999]

urlJMSRouteur=t3://xxxx:xxxxx [MsgId: MMSG-17999]

Connexion impossible au routeur SwiftMq de l'agence Cannot instantiate class:

weblogic.jndi.WLInitialContextFactory [MsgId: MMSG-17999]"

--------------------------------------------------------------------------------

Solution: Add the line DummyClassLoader.setContextClassLoader(); to the beginning of the script

When you initialize a Java application, you must initialize the ClassLoader. This ClassLoader is important because the JNDI will verify if it is loaded.

When you run your Vusers as processes, each process loads the default ClassLoader and there will not be a problem. However, when you run your Vusers as threads, the default ClassLoader will be loaded for the main process but all the threads will not load the ClassLoader and causes the above error. To resolve the issue, use a dummy class loader in order to "cheat" the JNDI.

Example:

DummyClassLoader.setContextClassLoader();

Setting DummyClassLoader will cause the JNDI to think that each thread loads its own DummyClassLoader.