Setup and Configuration

Previous Next Contents

4 Setup and Configuration

This chapter describes how to set up the JMS TCK and JavaTest harness software. Before proceeding with the instructions in this chapter, be sure to install all required software, as described in Chapter 3, "Installation."

After completing the instructions in this chapter, proceed to Chapter 5, "Executing Tests," for instructions on running the JMS TCK.

4.1 Configuring Your Environment to Run the TCK Against the Reference Implementation

After configuring your environment as described in this section, continue with the instructions in Section 4.6, "Using the JavaTest Harness Software."

Note

In these instructions, variables in angle brackets need to be expanded for each platform. For example, <TS_HOME> becomes $TS_HOME on Solaris/Linux and %TS_HOME% on Windows. In addition, the forward slashes (/) used in all of the examples need to be replaced with backslashes (\) for Windows. Finally, be sure to use the appropriate separator for your operating system when specifying multiple path entries (; on Windows, : on UNIX/Linux).

On Windows, you must escape any backslashes with an extra backslash in path separators used in any of the following properties, or use forward slashes as a path separator instead.

4.1.1 To Configure Your Environment for the JMS TCK

  1. Set the following environment variables in your shell environment:

    • JAVA_HOME to the directory in which Java SE 7 is installed

    • TS_HOME to the directory in which the JMS TCK 2.0 software is installed

    • JMS_HOME to the directory in which the JMS 2.0 RI has been installed

    • PATH to include the following directories: JAVA_HOME/bin, JMS_HOME/bin, and <TS_HOME>/tools/ant/bin

  2. Edit your <TS_HOME>/bin/ts.jte file and set the following properties:

    • jms.home to the directory in which you installed your JMS 2.0 implementation

    • jms.classes to the JAR file(s) that contain your JMS 2.0 implementation classes
      For example, if using the JMS 2.0 RI , the jms.classes property would be set to jms.classes=${ri.jars}.

    • impl.vi to the JMS 2.0 implementation being tested
      This property signals which configuration script to execute for the config.vi and clean.vi Ant targets. These targets handle starting and stopping the JMS implementation under test as well as creating and deleting all of the JMS administered objects and JMS users needed by the JMS TCK.
      The ts.jte file supports two JMS 2.0 Reference Implementations: JMS 2.0 RI and Oracle Open Message Queue Version 5.0 product.
      For example, if using the JMS 2.0 RI , the impl.vi property is set to impl.vi=ri. With this setting, the config.vi and clean.vi ant targets will invoke the script under <TS_HOME>/bin/xml/impl/ri/config.vi.xml.

    • user to a valid user name in the JMS implementation

    • password to the password for the user that was specifiedwith the user property

    • jms_timeout to the length of time used to receive messages

    • harness.log.port to the port number that will be used for logging

    • porting.ts.jmsObjects.class.1 to point to your porting implementation, if you implemented the TSJMSObjectInterface interface
      If you did not implement the interface, use the default setting.

  3. If your JMS 2.0 implementation does not support the MY_QUEUE, MY_TOPIC, MyQueueConnectionFactory, or MyTopicConnectionFactory JNDI names, you must provide your own implementation of the TSJMSObjectInterface interface. See Implementing the JMS TCK Porting Package Interface for additional infomation about the TSJMSObjectInterface interface.

  4. If you are using the JMS 2.0 RI on the Windows platform, edit the <TS_HOME>/bin/ts.jte file and add the drive letter to the admin.pass.file and jndi.fs.dir properties. The property settings for the Windows platform are as follows:

    admin.pass.file=C:/tmp/ripassword
    jndi.fs.dir=C:/tmp/ri_admin_objects

    Edit the <TS_HOME>/bin/xml/impl/ri/jndi.properties file and add the drive letter to the java.naming.provider.url property. The property setting for the Windows platform is as follows:

    java.naming.provider.url=file:///C:/tmp/ri_admin_objects

4.1.2 To Configure and Start Your JMS 2.0 Implementation

  1. Set JMS_HOME to the location where your JMS implementation has been installed.

  2. Start the JNDI service.

    Note

    A Vendor Implementation is not required to use a JNDI provider as the object store for JMS administered objects. For more information, see the TSJMSObjectsInterface, an interface that defines a porting layer for looking up the JMS administered objects. Vendors must either implement this porting package for their specific implementation or use the provided porting package and JNDI file system provider.

  3. Start your JMS implementation.

  4. Add the following administered objects:

    Name Type

    MY_QUEUE

    javax.jms.Queue

    MY_QUEUE2

    javax.jms.Queue

    testQ0

    javax.jms.Queue

    testQ1

    javax.jms.Queue

    testQ2

    javax.jms.Queue

    testQueue2

    javax.jms.Queue

    Q2

    javax.jms.Queue

    MY_TOPIC

    javax.jms.Topic

    MY_TOPIC2

    j`avax.jms.Topic`

    testT0

    javax.jms.Topic

    testT1

    j`avax.jms.Topic`

    testT2

    javax.jms.Topic

    MyConnectionFactory

    javax.jms.ConnectionFactory

    MyQueueConnectionFactory

    javax.jms.QueueConnectionFactory

    MyTopicConnectionFactory

    javax.jms.TopicConnectionFactory

    DURABLE_SUB_CONNECTION_FACTORY

    javax.jms.TopicConnectionFactory

Note

jms/DURABLE_SUB_CONNECTION_FACTORY must support durable subscriptions and must be created with clientID=cts.

The sections that follow explain how to automatically and manually create these administered objects using the JMS 2.0 RI.

automatic-configuration-and-startup-of-the-jms-ri]]

4.1.3 Automatic Configuration and Startup of the JMS RI

This section is optional. You do not have to start up and configure the JMS RI as part of the certification process. You may, however, want to do so to familiarize yourself with the testing process.

The steps in this section explain how to automatically handle the configuration and startup procedures, something you may want to do with your implementation, especially if you have want to test repeatedly. You can examine the provided scripts, then modify them for use with the implementaation under test. Section 4.1.4, "Manual Configuration and Startup of the JMS RI," provides the manual steps for doing what the provided scripts do automatically.

Complete the following steps to automatically configure and start up the JMS RI:

  1. Set the following environment variables in your shell environment:

    • JAVA_HOME to the directory in which the Java SE 7 software has been installed

    • IMQ_JAVAHOME to the value of JAVA_HOME.
      This is needed for JMS 2.0 RI commands and scripts.

    • TS_HOME to the directory in which the JMS TCK software has been installed

    • JMS_HOME to the directory in which your JMS 2.0 implementation has been installed

    • PATH to include the following directories: JAVA_HOME/bin, JMS_HOME/bin, and /bin`<TS_HOME>/tools/ant`

  2. If you are using the JMS 2.0 RI on the Windows platform, edit the <TS_HOME>/bin/ts.jte file and add the drive letter to the admin.pass.file and jndi.fs.dir properties. The property settings for the Windows platform are as follows:

admin.pass.file=C:/tmp/ripassword
jndi.fs.dir=C:/tmp/ri_admin_objects

Edit the <TS_HOME>/bin/xml/impl/ri/jndi.properties file and add the drive letter to the java.naming.provider.url property. The property setting for the Windows platform is as follows:

java.naming.provider.url=file:///C:/tmp/ri_admin_objects
  1. Invoke config.vi, the Ant configuration script, to start and configure the JMS RI.
    The JMS TCK comes with a configuration XML file, which automates starting and stopping the JMS service as well as creating and deleting all of the JMS administered objects and JMS users needed by the JMS TCK. Use the following command to invoke the configuration XML file to start and configure the JJMS TCK.

cd $TS_HOME/bin
ant config.vi

When used with the JMS 2.0 RI or the Oracle Open Message Queue 5.0 product, this target invokes the <TS_HOME>/bin/xml/impl/ri/config.vi.xml script, which starts the JMS service and creates the JMS administered objects and JMS users needed by the JMS TCK. In the ts.jte file, the JMS 2.0 implementation property, impl.vi, needs to be set to ri and the jms.classes property needs to be set to ${ri.jars} for the JMS RI or the Oracle Open Message Queue product.
To automate the process of creating the JMS administered obects and JMS users for your JMS implementation, provide your own Ant-based configuration file, name it <TS_HOME>/bin/xml/impl/vi/config.vi.xml, and set the impl.vi property to vi in your ts.jte file. When you execute the ant config.vi target, the script invokes and executes your script <TS_HOME>/bin/xml/impl/vi/config.vi.xml. 4. Invoke clean.vi, an Ant configuration script, to stop and unconfigure the JMS RI.
The JMS TCK comes with an XML configuration file that automates starting and stopping the JMS service as well as creating and deleting all of the JMS administered objects and JMS users needed by the JMS TCK. Use the following command to invoke the configuration XML file to stop and unconfigure the JMS RI.

cd $TS_HOME/bin
ant clean.vi

If you are using the JMS RI or the Oracle Open Message Queue product, this target invokes the <TS_HOME>/bin/xml/impl/ri/config.vi.xml script which stops the JMS service and deletes all the JMS administered objects and JMS users needed by the JMS TCK. In the ts.jte file, set the impl.vi property to ri and the jms.classes property to ${ri.jars} for the JMS RI or the Oracle Open Message Queue product.

4.1.4 Manual Configuration and Startup of the JMS RI

This section is optional. You do not have to start up and configure the JMS RI as part of the certification process. You may, however, want to do so to familiarize yourself with the testing process.

The steps in this section explain how to manually configure and start up the JMS RI, something you will do with your implementation. If you have to test repeatedly, you may want to examine the provided scripts that automate the configuration and startup procedures, then modify them for use with the implementaation under test. Section 4.1.3, "Automatic Configuration and Startup of the JMS RI," provides the steps for using the provided scripts do perform these steps automatically.

Complete the following steps to manually configure and start up the JMS RI:

  1. Set the following environment variables in your shell environment:

    • JAVA_HOME to the directory in which the Java SE 7 software has been installed

    • IMQ_JAVAHOME to the value of JAVA_HOME.
      This is needed for JMS 2.0 RI commands and scripts.

    • TS_HOME to the directory in which the JMS TCK Version 2.0 software has been installed

    • JMS_HOME to the directory in which your JMS 2.0 implementation has been installed

    • PATH to include the following directories: JAVA_HOME/bin, JMS_HOME/bin, and <TS_HOME>/tools/ant/bin

  2. Use the following command to start the JMS Message Queue Broker Service:

    (UNIX) $JMS_HOME/bin/imqbrokerd
  3. Use the following command to create the j2ee TCK user in the JMS Message Queue user repository:

    (UNIX) $JMS_HOME/bin/imqusermgr add -f -u j2ee -p j2ee -g admin
  4. Use the following command to create the file system directory as the object store for the JMS Administered Objects:

    (UNIX) mkdir /tmp/ri_admin_objects

    This directory must match the jndi.fs.dir. property setting in the ts.jte file and the java.naming.provider.url property in the <TS_HOME>/bin/xml/impl/ri/jndi.properties file.

  5. Create the following JMS administered objects:

    Name Type

    MY_QUEUE

    javax.jms.Queue

    MY_QUEUE2

    javax.jms.Queue

    testQ0

    javax.jms.Queue

    testQ1

    javax.jms.Queue

    testQ2

    javax.jms.Queue

    testQueue2

    javax.jms.Queue

    Q2

    javax.jms.Queue

    MY_TOPIC

    javax.jms.Topic

    MY_TOPIC2

    j`avax.jms.Topic`

    testT0

    javax.jms.Topic

    testT1

    j`avax.jms.Topic`

    testT2

    javax.jms.Topic

    MyConnectionFactory

    javax.jms.ConnectionFactory

    MyQueueConnectionFactory

    javax.jms.QueueConnectionFactory

    MyTopicConnectionFactory

    javax.jms.TopicConnectionFactory

    DURABLE_SUB_CONNECTION_FACTORY

    javax.jms.TopicConnectionFactory

Use the following commands to create the MY_QUEUE and MY_TOPIC JMS administered objects.

$JMS_HOME/bin/imqobjmgr -f add -l MY_QUEUE -o imqDestinationName=MY_QUEUE -t q \
-j java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory \
-j java.naming.provider.url=file:////tmp/ri_admin_objects

$JMS_HOME/bin/imqobjmgr -f add -l MY_TOPIC -o imqDestinationName=MY_TOPIC -t t \
-j java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory \
-j java.naming.provider.url=file:////tmp/ri_admin_objects

Use the following commands to create the MyConnectionFactory, MyQueueConnectionFactory, and MyTopicConnectionFactory JMS administered objects.

$JMS_HOME/bin/imqobjmgr -f add -l MyConnectionFactory -t cf \
-j java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory \
-j java.naming.provider.url=file:////tmp/ri_admin_objects

$JMS_HOME/bin/imqobjmgr -f add -l MyQueueConnectionFactory -t qf \
-j java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory \
-j java.naming.provider.url=file:////tmp/ri_admin_objects

$JMS_HOME/bin/imqobjmgr -f add -l MyTopicConnectionFactory -t tf \
-j java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory \
-j java.naming.provider.url=file:////tmp/ri_admin_objects

The DURABLE_SUB_CONNECTION_FACTORY administered object must support durable subscriptions and must be created with clientID=cts. Use the following command to create the DURABLE_SUB_CONNECTION_FACTORY administered object.

$JMS_HOME/bin/imqobjmgr -f add -l DURABLE_SUB_CONNECTION_FACTORY \
-o imqConfiguredClientID=cts -t tf \
-j java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory \
-j java.naming.provider.url=file:////tmp/ri_admin_objects

4.2 Implementing the JMS TCK Porting Package Interface

You may need to provide your own implementation of the TSJMSObjectsInterface porting package interface that is provided with the JMS TCK.

Note that if you do implement this interface, you will also need to set the porting.ts.jmsObjects.class.1 property in the ts.jte file for accessing your porting implementation class. The default for this property value is set to the implementation used by the JMS Reference Implementation. You may need to set this value to point to your implementation of this interface. See Manual Configuration and Startup of the JMS RI for information about modifying the ts.jte file.

The TSJMSObjectsInterface interface looks like this:

public interface TSJMSObjectsInterface {
public Queue getQueue(java.lang.String name)
        throws java.lang.Exception;
public Topic getTopic(java.lang.String name)
        throws java.lang.Exception;
public TopicConnectionFactory
        getTopicConnectionFactory(java.lang.String name)
throws java.lang.Exception;
        public QueueConnectionFactory
getQueueConnectionFactory(java.lang.String name)
        throws java.lang.Exception;
        public ConnectionFactory
getConnectionFactory(java.lang.String name)
        throws java.lang.Exception;
}

where:

  • The getQueue method, which is used to get a Queue, accepts the name of the queue as an input parameter.

  • The getTopic method, which is used to get a Topic, accepts the name of the topic as an input parameter.

  • The getTopicConnectFactory method, which is used to get a TopicConnectionFactory, accepts the name of the TopicConnectionFactory as an input parameter.

  • The getQueueConnectionFactory method, which is used to get a QueueConnectionFactory, accepts the name of the QueueConnectionFactory as an input parameter.

  • The getConnectionFactory method, which is used to get a ConnectionFactory, accepts the name of the ConnectionFactory as an input parameter.

Make sure that you set the value of the porting.ts.jmsObjects.class.1 property in the ts.jte file to point to your implementation of the TSJMSObjectsInterface. Refer to Manual Configuration and Startup of the JMS RI for information about the list of administered objects you may need to manually create.

A sample implementation of the TSJMSObjectsInterface porting package, SunRIJMSObjects.java, is provided with the JMS TCK and can be found in the <TS_HOME>/src/com/sun/ts/lib/implementation/sun/jms. directory.

4.3 Publishing the Test Applications

Not needed for the JMS TCK.

4.4 Custom Configuration Handlers

Configuration handlers are used to configure and unconfigure a JMS 2.0 implementation during the certification process. These are similar to deployment handlers but used for configuration. A configuration handler is an Ant build file that contains at least the required targets listed below: * config.vi - to configure the vendor implementation * clean.vi - to unconfigure the vendor implementation

These targets are called from the <TS_HOME>/bin/build.xml file and call down into the implementation-specific configuration handlers.

To provide your own configuration handler, create a config.vi.xml file with the necessary configuration steps for your implementation and place the file under the <TS_HOME>/bin/xml/impl/<your_impl> directory.

For more information, see <TS_HOME>/bin/xml/impl/glassfish/config.vi.xml, the configuration file for the Java EE 8 RI.

4.5 Custom Deployment Handlers

Deployment handlers are used to deploy and undeploy the WAR files that contain the tests to be run during the certification process. A deployment handler is an Ant build file that contains at least the required targets listed in the table below.

The JMS TCK provides these deployment handlers: * <TS_HOME>/bin/xml/impl/none/deploy.xml * <TS_HOME>/bin/xml/impl/glassfish/deploy.xml

The deploy.xml files in each of these directories are used to control deployment to a specific container (no deployment, deployment to the GlassFish Web container, deployment to the Tomcat Web container) denoted by the name of the directory in which each deploy.xml file resides. The primary build.xml file in the <TS_HOME>/bin directory has a target to invoke any of the required targets (-deploy, -undeploy, -deploy.all, -undeploy.all).

4.5.1 To Create a Custom Deployment Handler

To deploy tests to another JMS implementation, you must create a custom handler. 1. Create a new directory in the <TS_HOME>/bin/impl directory tree. For example, create the <TS_HOME>/bin/impl/my_deployment_handler directory. Replace my_deployment_handler with the value of the impl.vi property that you set in Step 5 of the configuration procedure described in Section 4.2, "Configuring Your Environment to Repackage and Run the TCK Against the Vendor Implementation".

  1. Copy the deploy.xml file from the <TS_HOME>/bin/xml/impl/none directory to the directory that you created.

  2. Modify the required targets in the deploy.xml file. This is what the deploy.xml file for the "none" deployment handler looks like.

    <project name="No-op Deployment" default="deploy">
        <!-- No-op deployment target -->
        <target name="-deploy">
            <echo message="No deploy target implemented for this deliverable"/>
        </target>
        <target name="-undeploy">
            <echo message="No undeploy target implemented for this deliverable"/>
        </target>
        <target name="-deploy.all">
            <echo message="No deploy target implemented for this deliverable"/>
        </target>
        <target name="-undeploy.all">
            <echo message="No undeploy target implemented for this deliverable"/>
        </target>
    </project>

    Although this example just echoes messages, it does include the four required Ant targets (-deploy, -undeploy, -deploy.all, -undeploy.all) that your custom deploy.xml file must contain. With this as your starting point, look at the required targets in the deploy.xml files in the tomcat and glassfish directories for guidance as you create the same targets for the Web container in which you will run your implementation of JMS.

The following Ant targets can be called from anywhere under the <TS_HOME>/src directory:

  • deploy

  • undeploy

  • deploy.all

  • undeploy.all

The deploy.all and undeploy.all targets can also be called from the <TS_HOME>/bin directory.

Note

The targets in the deploy.xml file are never called directly. They are called indirectly by the targets listed above.

4.6 Using the JavaTest Harness Software

There are two general ways to run the JMS TCK test suite using the JavaTest harness software:

4.7 Using the JavaTest Harness Configuration GUI

You can use the JavaTest harness GUI to modify general test settings and to quickly get started with the default JMS TCK test environment. This section covers the following topics:

Note

It is only necessary to proceed with this section if you want to run the JavaTest harness in GUI mode. If you plan to run the JavaTest harness in command-line mode, skip the remainder of this chapter, and continue with Chapter 5, "Executing Tests."

4.7.1 Configuration GUI Overview

In order for the JavaTest harness to execute the test suite, it requires information about how your computing environment is configured. The JavaTest harness requires two types of configuration information:

  • Test environment: This is data used by the tests. For example, the path to the Java runtime, how to start the product being tested, network resources, and other information required by the tests in order to run. This information does not change frequently and usually stays constant from test run to test run.

  • Test parameters: This is information used by the JavaTest harness to run the tests. Test parameters are values used by the JavaTest harness that determine which tests in the test suite are run, how the tests should be run, and where the test reports are stored. This information often changes from test run to test run.

The first time you run the JavaTest harness software, you are asked to specify the test suite and work directory that you want to use. (These parameters can be changed later from within the JavaTest harness GUI.)

Once the JavaTest harness GUI is displayed, whenever you choose Start, then Run Tests to begin a test run, the JavaTest harness determines whether all of the required configuration information has been supplied:

  • If the test environment and parameters have been completely configured, the test run starts immediately.

  • If any required configuration information is missing, the configuration editor displays a series of questions asking you the necessary information. This is called the configuration interview. When you have entered the configuration data, you are asked if you wish to proceed with running the test.

4.7.2 Starting the Configuration GUI

Before you start the JavaTest harness software, you must have a valid test suite and Java SE 8 installed on your system.

The JMS TCK includes an Ant script that is used to execute the JavaTest harness from the <TS_HOME> directory. Using this Ant script to start the JavaTest harness is part of the procedure described in Section 4.7.3, "To Configure the JavaTest Harness to Run the TCK Tests."

When you execute the JavaTest harness software for the first time, the JavaTest harness displays a Welcome dialog box that guides you through the initial startup configuration.

  • If it is able to open a test suite, the JavaTest harness displays a Welcome to JavaTest dialog box that guides you through the process of either opening an existing work directory or creating a new work directory as described in the JavaTest online help.

  • If the JavaTest harness is unable to open a test suite, it displays a Welcome to JavaTest dialog box that guides you through the process of opening both a test suite and a work directory as described in the JavaTest documentation.

After you specify a work directory, you can use the Test Manager to configure and run tests as described in Section 4.7.3, "To Configure the JavaTest Harness to Run the TCK Tests."

4.7.3 To Configure the JavaTest Harness to Run the TCK Tests

The answers you give to some of the configuration interview questions are specific to your site. For example, the name of the host on which the JavaTest harness is running. Other configuration parameters can be set however you wish. For example, where you want test report files to be stored.

Note that you only need to complete all these steps the first time you start the JavaTest test harness. After you complete these steps, you can either run all of the tests by completing the steps in Section 5.1, "Starting JavaTest," or run a subset of the tests by completing the steps in Section 5.2, "Running a Subset of the Tests."

  1. Change to the <TS_HOME>/bin directory and start the JavaTest test harness:
    cd <TS_HOME>/bin
    ant gui

  2. From the File menu, click Open Quick Start Wizard.
    The Welcome screen displays.

  3. Select Start a new test run, and then click Next.
    You are prompted to create a new configuration or use a configuration template.

  4. Select Create a new configuration, and then click Next.
    You are prompted to select a test suite.

  5. Accept the default suite (<TS_HOME>/src), and then click Next.
    You are prompted to specify a work directory to use to store your test results.

  6. Type a work directory name or use the Browse button to select a work directory, and then click Next.
    You are prompted to start the configuration editor or start a test run. At this point, the JMS TCK is configured to run the default test suite.

  7. Deselect the Start the configuration editor option, and then click Finish.

  8. Click Run Tests, then click Start.
    The JavaTest harness starts running the tests.

  9. To reconfigure the JavaTest test harness, do one of the following:

    • Click Configuration, then click New Configuration.

    • Click Configuration, then click Change Configuration.

  10. Click Report, and then click Create Report.

  11. Specify the directory in which the JavaTest test harness will write the report, and then click OK.
    A report is created, and you are asked whether you want to view it.

  12. Click Yes to view the report.

4.7.4 Modifying the Default Test Configuration

The JavaTest GUI enables you to configure numerous test options. These options are divided into two general dialog box groups:

  • Group 1: Available from the JavaTest Configure/Change Configuration submenus, the following options are displayed in a tabbed dialog box:

    • Tests to Run

    • Exclude List

    • Keywords

    • Prior Status

    • Test Environment

    • Concurrency

    • Timeout Factor

  • Group 2: Available from the JavaTest Configure/Change Configuration/Other Values submenu, or by pressing Ctrl+E, the following options are displayed in a paged dialog box:

    • Environment Files

    • Test Environment

    • Specify Tests to Run

    • Specify an Exclude List

Note that there is some overlap between the functions in these two dialog boxes; for those functions use the dialog box that is most convenient for you. Please refer to the JavaTest Harness documentation or the online help for complete information about these various options.


Previous Next Contents
Eclipse Foundation Logo  Copyright © 2018, Oracle and/or its affiliates. All rights reserved.