Setup and Configuration

## 4 Setup and Configuration

Note | The Jakarta EE Specification process provides for any number of compatible implementations. As additional implementations become available, refer to project or product documentation from those vendors for specific TCK setup and operational guidance.

This chapter describes how to set up the XML RPC 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 XML RPC 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.3, "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.

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

   1. `JAVA_HOME` to the directory in which Java SE 8 is installed

   2. `TS_HOME` to the directory in which the XML RPC TCK 1.1 software is installed

   3. `JWSDP_HOME` to the directory in which the XML RPC 1.1 CI has been installed

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

2. Edit your `<TS_HOME>/bin/build.properties` file and set the following environment variables:

   1. Set the `webserver.home` property to the directory in which the Java Web Services Developers Pack 1.3 software is installed.
      By default this is `${env.JWSDP_HOME}`.

   2. Set the `webserver.host` property to the host on which the Web server is running.
      By default this is `localhost`.

   3. Set the `webserver.port` property to the port on which the web Server is running.

   4. Set the `j2ee.home.ri` property to the directory in which the J2SE software is installed, for reference to the packager tool used by the build infrastructure. You only need to set this property if you want to build the XML RPC TCK software.

   5. Set the `jaxrpc.home` property to the path for Java Web Services Developers Pack, which contains the XML RPC mapping tool (formerly JAX-RPC), is installed.

   6. Set the `jaxrpc.tool` property to the path where the XML RPC 1.1 `JavaToWSDL` and `WSDLToJava` mapping tool exists.
      By default this is `<JWSDP_HOME>/jaxrpc/bin/wscompile.sh`.

   7. Set the local_classes property to point to the XML RPC CI classes/jars and the TCK classes/jars (tsharness.jar, javatest.jar, jaxrpctck.jar). For the Java Web Services Developers Pack (JWSDP 1.3) your `local_classes` property setting is:

          local_classes=${env.JWSDP_HOME}/jaxp/lib/jaxp-api.jar:
          ${env.JWSDP_HOME}/jaxp/lib/endorsed/xercesImpl.jar:
          ${env.JWSDP_HOME}/jaxp/lib/endorsed/xsltc.jar:
          ${env.JWSDP_HOME}/jaxp/lib/endorsed/xalan.jar:
          ${env.JWSDP_HOME}/jaxp/lib/endorsed/sax.jar:
          ${env.JWSDP_HOME}/jaxp/lib/endorsed/dom.jar:
          ${env.JWSDP_HOME}/saaj/lib/saaj-impl.jar:
          ${env.JWSDP_HOME}/saaj/lib/saaj-api.jar:
          ${env.JWSDP_HOME}/jaxrpc/lib/jaxrpc-impl.jar:
          ${env.JWSDP_HOME}/jaxrpc/lib/jaxrpc-api.jar:
          ${env.JWSDP_HOME}/jaxrpc/lib/jaxrpc-spi.jar:
          ${env.JWSDP_HOME}/jwsdp-shared/lib/mail.jar:
          ${env.JWSDP_HOME}/jwsdp-shared/lib/activation.jar:
          ${env.JWSDP_HOME}/jwsdp-shared/lib/commons-logging.jar:
          ${env.JWSDP_HOME}/jwsdp-shared/lib/jax-qname.jar:
          ${env.JWSDP_HOME}/jwsdp-shared/lib/relaxngDatatype.jar:
          ${env.JWSDP_HOME}/jwsdp-shared/lib/xsdlib.jar:
          ${env.JWSDP_HOME}/jwsdp-shared/lib/jaas.jar:
          ${env.TS_HOME}/lib/javatest.jar:${env.TS_HOME}/lib/
          tsharness.jar:
          ${env.TS_HOME}/lib/jaxrpctck.jar:${env.JWSDP_HOME}/common/
          lib/servlet-api.jar

3. Provide your own implementation of the porting package interface provided with the XML RPC TCK.

   - The porting package interface, `TSURLInterface.java`, obtains URL strings for web resources in an implementation-specific manner.

   - `TSJAXRPCInterface.java` – Obtains RPC service endpoint URLs and WSDL service file location URLs in a vendor-specific manner using standard properties that map to the URL values supplied by the vendor and to obtain Service Implementation Classes in a vendor-specific manner.
     API documentation for the `TSURLInterface.java` porting package interface is available in the XML RPC TCK documentation bundle.

4. Edit your `<TS_HOME>/bin/ts.jte` file and modify the following environment settings (These settings would work for Eclipse GlassGish 5.1 CI):

   1. Set the `webServerHost` property to the name of the host on which Jakarta EE 8 CI is running.
      The default setting is `localhost`.

   2. Set the `webServerPort` property to the port number of the host on which Jakarta EE 8 CI is running.
      The default setting is `8080`.

   3. Set the `secureWebServerPort` property to the secure SSL HTTP/1.1 port number of the host on which the web server is running.+ The default setting is `8443`.

   4. Set the `user` and `password` properties to the user and password used for the basic authentication tests.
      The default setting is `j2ee` for both.

   5. Set the `authuser` and `authpassword` properties to the user and password used for the basic authentication tests.
      The default setting is `javajoe` for both.

   6. Set the `porting.ts.url.class.1` property to your porting implementation class that is used for obtaining URLs.
      The default setting for the Eclipse EE4J CI porting implementation is:
      `com.sun.ts.lib.implementation.sun.common.SunRIURL`.

   7. Set the porting.ts.jaxrpc.class.1 property to your porting implementation class that is used for obtaining service implementation classes, port information, and URLs for service endpoints and WSDL locations.+ The default setting for the Eclipse EE4J CI porting implementation is:
      `com.sun.ts.lib.implementation.sun.jaxrpc.SunRIJAXRPC`

### 4.2 Configuring Your Environment to Repackage and Run the TCK Against the Vendor Implementation

After configuring your environment as described in this section, continue with the instructions in Section 4.3, "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.2.1 Running the XML RPC TCK on a Vendor’s Implementation

The XML RPC 1.1 specification does not specify any normative model for packaging and deployment of service endpoints on a servlet container-based XML RPC runtime system. A XML RPC 1.1 implementation is allowed to have a vendorspecific deployment and packaging model for servlet-based service endpoints. For this reason, the XML RPC TCK provides two distribution directories, /dist and /dist-vi, for the web service endpoint tests.

The /dist directory contains all the WAR files for the XML RPC TCK service endpoint tests that have been compiled and packaged for deployment on a Servlet-compliant web container using the standard Web Archive (WAR) format. These WAR files are tailored for use with the XML RPC 1.1 Reference Implementation. The web.xml file contains the deployment information that the web container needs to link XML RPC service endpoints to its associated servlet class. One generic servlet class, com.sun.xml.rpc.server.http.JAXRPCServlet , is used for all XML RPC service endpoints. These WAR files enable you to run, without any additional setup or modification, the XML RPC TCK tests and to test the various features and functionality of the XML RPC 1.1 Reference Implementation.

The /dist-vi directory contains generic JAR files for all the TCK service endpoint tests that you must use to package and deploy on your XML RPC 1.1 implementation in a vendor-specific way. For each of these web applications, you must use your deployment tool to perform the appropriate Java-to-WSDL or WSDL-to-Java mapping, based on whether the service endpoint is defined by a Java Service Endpoint Interface or a WSDL service document. Next, you must package all the generated artifacts needed along with the service implementation classes for the service endpoints and deploy them on your container-based implementation.

The following README files and TABLE show test breakdown and provide information that should help you with this process

- README.JAVA-TO-WSDL

- README.WSDL-TO-JAVA

- Test Breakdown and Mapping Requirements

These README files contain the manual instructions that you need to perform to implementation. The files also specify the mapping (Java-to-WSDL or WSDL-to- deploy and package the service endpoint tests on your XML RPC 1.1 Java) that each test must perform. + For a brief example of how the XML RPC 1.1 Reference Implementation does this, look at the J2WMT.war web application in the the /dist directory. This test marshalls/unmarshalls all the XML RPC-supported Java data types as outlined in the XML RPC 1.1 Specification using the Java-to-WSDL mapping. The web.xml file that is packaged in this web application is as follows:

    <?xml version="1.0" encoding="UTF-8"?>
    <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://
    java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
    <display-name>J2WMarshallTestApp</display-name>
    <listener>
    <listenerclass>
    com.sun.ts.tests.jaxrpc.common.JAXRPCContextListener</
    listener-class>
    </listener>
    <servlet>
    <servlet-name>XmlServletName</servlet-name>
    <servlet-class>com.sun.ts.tests.jaxrpc.common.JAXRPCServlet</
    servlet-class>
    <load-on-startup>0</load-on-startup>
    </servlet>
    <servlet-mapping>
    <servlet-name>XmlServletName</servlet-name>
    <url-pattern>/jaxrpc/*</url-pattern>
    </servlet-mapping>
    <session-config>
    <session-timeout>54</session-timeout>
    </session-config>
    </web-app>

As you can see, the XML RPC service endpoint is linked to a generic servlet in the XML RPC CI (com.sun.xml.rpc.server.http.JAXRPCServlet). This servlet is abstracted out in XML RPC TCK under common servlet (com.sun.ts.tests.jaxrpc.common.JAXRPCServlet) which simply extends it. This common servlet is used for processing, handling and dispatching to all JAX-RPC service endpoints. The XML RPC TCK Service Endpoint WAR files use a consistent naming convention for accessing all Service Endpoint URLs and WSDL URLs: as follows.

- For Service Endpoint URLs, the URL mapping follows this convention: http://webServerHost:webServerPort/ContextRoot/URLAlias/PortName
  The URL Alias used in all JAX-RPC TCK tests is jaxrpc.

- For WSDL URL locations, the URL mapping follows this convention: http://webServerHost:webServerPort/ContextRoot/URLAlias?WSDL

The example that follows is one of the JAX-RPC TCK tests that shows this mapping.

The following implementation-specific runtime configuration file, jaxrpc-riruntime. xml , is supplied as a web archive initialization file to this servlet. This runtime configuration file is automatically generated by the wsdeploy deployment tool, which gives information on all service endpoints containing their interface, implementation and tie classes, their service, port and WSDL document and their URL pattern for accessing the endpoint.

    <?xml version="1.0" encoding="UTF-8"?>
    <endpoints xmlns=’http://java.sun.com/xml/ns/jax-rpc/ri/runtime’ version=’1.0’>
    <endpoint
      name=’MarshallTest’
      interface=’com.sun.ts.tests.jaxrpc.ee.j2w.marshalltest.Marshall Test’
      implementation=’com.sun.ts.tests.jaxrpc.ee.j2w.marshalltest.MarshallTestImpl’
      tie=’com.sun.ts.tests.jaxrpc.ee.j2w.marshalltest.MarshallTest_Tie’
      wsdl=’/WEB-INF/MarshallTestService.wsdl’
      service=’{http://marshalltestservice.org/wsdl}MarshallTestService’
      port=’{http://marshalltestservice.org/wsdl}MarshallTestPort’
      urlpattern=’/jaxrpc/MarshallTest’/>
    </endpoints>

The RPC service endpoint has one port defined in its runtime configuration file. The test client code accesses this XML RPC service endpoint and port at the following URL location:
http://webServerHost:webServerPort/J2WMT/jaxrpc/MarshallTest

where MarshallTest is the service port to access.

The above RPC service endpoint WSDL file describing this service is also published. The test client code accesses this WSDL file based on the above configuration via the following URL location:
http://webServerHost:webServerPort/J2WMT/jaxrpc/MarshallTest?WSDL

#### 4.2.2 Instructions for Interoperability Test Scenarios

To test for interoperability between your implementation and the XML RPC Reference Implementation, we recommend the following two test scenarios:

- J2WMT

- W2JMarshallTest

Complete the following steps to test interoperability between XML RPC implementations in both directions:

1. Deploy and run the J2WMT and W2JMarshallTest TCK tests on your own XML RPC 1.1 implementation and perform the appropriate mappings (WSDL-to-Java) and (Java-to-WSDL)

2. Deploy the XML RPC CI WAR files (J2WMT.war) and (W2JMarshallTest.war) on a remote host system using the XML RPC 1.1 Reference Implementation.

3. On your local host system that is running your own XML RPC implementation, edit the ts.jte file to change the Web server host and port to point to this remote system running the XML RPC CI with the J2WMT.war and W2JMarshallTest.war WAR files deployed.

4. Run the client code for these tests against the remote system to test the marshalling/unmarshalling of data from your XML RPC implementaton to the XML RPC CI implementation system and back.

5. Perform the same procedure going in the opposite direction, running the client on the XML RPC CI and accessing the Service Endpoint deployed on your XML RPC implementation.

### 4.4 Custom Configuration Handlers

Configuration handlers are used to configure and unconfigure a XML RPC 1.1 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, you may wish to view `<TS_HOME>/bin/xml/impl/glassfish/config.vi.xml`, the configuration file for Eclipse EE4J Jakarta EE 8 Compatible Implementation, Eclipse GlassFish.

### 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 XML RPC TCK provides these deployment handlers:

- `<TS_HOME>/bin/xml/impl/none/deploy.xml`

- `<TS_HOME>/bin/xml/impl/glassfish/deploy.xml`

- `<TS_HOME>/bin/xml/impl/tomcat/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 Eclipse 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 XML RPC implementation, you must create a custom handler.

1. Create a new directory in the `<TS_HOME>/bin/xml/impl` directory tree. For example, create the `<TS_HOME>/bin/xml/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".

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

3. 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 Eclipse Glassfish directories for guidance as you create the same targets for the Web container in which you will run your implementation of XML RPC.

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 XML RPC TCK test suite using the JavaTest harness software:

- Through the JavaTest GUI; if using this method, please continue on to Section 4.7, "Using the JavaTest Harness Configuration GUI."

- In JavaTest batch mode, from the command line in your shell environment; if using this method, please proceed directly to Chapter 5, "Executing Tests."

### 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 XML RPC TCK test environment. This section covers the following topics:

- Configuration GUI Overview

- Starting the Configuration GUI

- To Configure the JavaTest Harness to Run the XML RPC TCK Tests

- Modifying the Default Test Configuration

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 XML RPC 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 XML RPC 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.

Copyright © 2018, Oracle and/or its affiliates. All rights reserved.