Setup and Configuration

Previous Next Contents

5 Setup and Configuration

This chapter describes how to set up the Jakarta EE 9 Platform TCK test suite and configure it to work with your test environment. It is recommended that you first set up the testing environment using the Jakarta EE 9 CI and then with your Jakarta EE 9 server.

This chapter includes the following topics:

5.1 Allowed Modifications

You can modify the following test suite components only:

  • Your implementation of the porting package

  • ts.jte environment file

  • The vendor-specific SQL files in <TS_HOME>/sql

  • Any files in <TS_HOME>/bin and <TS_HOME>/bin/xml (except for ts.* files)

5.2 Configuring the Test Environment

The instructions in this section and in Section 5.3.3, "Configuring Your Application Server as the VI," step you through the configuration process for the Solaris, Microsoft Windows, and Linux platforms.

All TCK test configuration procedures are based on running the Ant scripts against a set of build targets. The primary location of any configuration settings you are likely to make is the <TS_HOME>/bin/ts.jte environment file. You may also want to modify the javaee_vi.xml and initdb.xml Ant configuration files and the vendor-specific SQL files. These two files contain predefined Ant targets that are implemented such that they automatically configure the Jakarta EE 9 CI and its associated database in order to pass the TCK. A Implementer may choose to implement these targets to work with their server environment to perform the steps described in Section 5.3.3, "Configuring Your Application Server as the VI."

Note

Ant targets are available at all levels of the TCK source tree that allow you to execute a wide variety of test scenarios and configurations.

Before You Begin

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.

  1. Identify the software pieces and assemble them into the Jakarta EE 9 platform to be tested for certification.

  2. Implement the porting package APIs.
    Some functionality in the Jakarta EE 9 platform is not completely specified by an API. To handle this situation, the Jakarta EE 9 Platform TCK test suite defines a set of interfaces in the com.sun.cts.porting package, which serve to abstract any implementation-specific code. You must create your own implementations of the porting package interfaces to work with your particular Jakarta EE 9 server environment. See Section 11.2, "Porting Package APIs," for additional information about the porting APIs. API documentation for the porting package interfaces is available in the <TS_HOME>/docs/api directory.

  3. Set up the Jakarta Platform, Enterprise Edition Compatible Implementation (CI) server.
    See Section 5.3.2, "Configuring the Jakarta EE 9 CI as the VI," for a list of the modifications that must be made to run CTS against the Jakarta EE 9 CI.

  4. Set up the vendor’s Jakarta EE 9 server implementation (VI).
    See Section 5.3.3, "Configuring Your Application Server as the VI," for a list of the modifications that must be made to run CTS against the vendor’s Jakarta EE 9 server.

  5. Validate your configuration.
    Run the sample tests provided. If the tests pass, your basic configuration is valid. See Section 7.3, "Validating Your Test Configuration," for information about using JavaTest to run the sample tests.

  6. Run the TCK tests.
    See Chapter 7, "Executing Tests," for information about Starting JavaTest and running tests.

5.3 Configuring a Jakarta EE 9 Server

This section describes how to configure the Jakarta EE 9 server under test. You can run the TCK tests against the Jakarta EE 9 CI or your own Jakarta Platform, Enterprise Edition server. When performing interoperability (interop) tests or web service-based tests, you will be running two Jakarta EE 9 CI servers, one of which must be a Jakarta EE 9 CI using, or configured to use a database. For example, Eclipse GlassFish 6.0 is bundled and configured to use the Apache Derby database.

For the purposes of this section, it is useful to clarify three terms as they are used here:

  • Compatible Implementation (CI): Jakarta EE 9 CI, for example, Eclipse GlassFish 6.0

  • Vendor Implemention (VI): Jakarta EE 9 implementation from a vendor other than Eclipse; typically, the goal of running the TCK is to certify a Jakarta EE 9 VI; in some cases, for purposes of familiarizing yourself with TCK, you may choose to run the Jakarta EE 9 CI as the VI

  • Bundled Derby: Apache Derby database bundled with the Jakarta EE 9 CI, Eclipse GlassFish 6.0

5.3.1 Jakarta Platform, Enterprise Edition Server Configuration Scenarios

There are three general scenarios for configuring Jakarta EE 9 servers for Jakarta EE 9 Platform TCK testing (Note: in the following images, Java EE refers to Jakarta EE. RI should be replaced with CI for Compatible Implementation):

  • Configure the Jakarta EE 9 CI as the server under test
    CI as Server Under Test

Use the Jakarta EE 9 CI as the Jakarta EE 9 VI; you may want to do this as a sanity check to make sure you are comfortable with using the Jakarta EE 9 TCK against a known standard CI with certified sample applications before proceeding with tests against your Jakarta EE 9 VI. See Section 5.3.2, "Configuring the Jakarta EE 9 CI as the VI," for instructions.

  • Configure your Jakarta EE 9 VI as Server Under Test
    VI as Server Under Test

This is the primary goal of using the Jakarta EE 9 Platform TCK; you will eventually need to configure the Jakarta EE 9 implementation you want to certify. See Section 5.3.3, "Configuring Your Application Server as the VI," for instructions.

  • Configure two Jakarta EE 9 servers for the purpose of interop testing
    Two Servers for Interop Testing

Rebuildable tests require that you configure two Jakarta EE 9 servers on one or two machines. One server will be your Jakarta EE 9 VI running a database of your choice with JDBC 4.1-compliant drivers. The second server must be the Jakarta EE 9 CI using the bundled Java DB database.

In terms of the Jakarta EE 9 Platform TCK, all TCK configuration settings are made in the <TS_HOME>/bin/ts.jte file. When configuring a Jakarta EE 9 server, the important thing is to make sure that the settings you use for your server match those in the ts.jte file.

These configuration scenarios are described in the following sections.

5.3.2 Configuring the Jakarta EE 9 CI as the VI

To configure the Jakarta EE 9 CI as the server under test (that is, to use the Jakarta EE 9 CI as the VI) follow the steps listed below. In this scenario, the goal is simply to test the Jakarta EE 9 CI against the CTS for the purposes of familiarizing yourself with TCK test procedures. You may also want to refer to the Quick Start guides included with the Jakarta EE 9 TCK for similar instructions.

  1. Set server properties in your <TS_HOME>/bin/ts.jte file to suit your test environment.
    Be sure to set the following properties:

    1. Set the webServerHost property to the name of the host on which your Web server is running that is configured with the CI.
      The default setting is localhost.

    2. Set the webServerPort property to the port number of the host on which the Web server is running and configured with the CI.
      The default setting is 8001.

    3. Set the wsgen.ant.classname property to the Vendor’s implementation class that mimics the CI Ant task that in turn calls the wsgen Java-to-WSDL tool.
      The default setting is com.sun.tools.ws.ant.WsGen.

    4. Set the wsimport.ant.classname property to the Vendor’s implementation class that mimics the CI Ant task that in turn calls the wsimport WSDL-to-Java tool.
      The default setting is com.sun.tools.ws.ant.WsImport.

    5. Set the porting.ts.url.class property to your porting implementation class that is used for obtaining URLs.
      The default setting for the CI porting implementation is com.sun.ts.lib.implementation.sun.common.SunRIURL.

    6. Set the database-related properties in the <TS_HOME>/bin/ts.jte file.
      Section C.3, "Database Properties in ts.jte," lists the names and descriptions for the database properties you need to set.

    7. Add the following JVM option to the command.testExecuteAppClient property to enable the Security Manager in the application client container:

      -Djava.security.manager

      Add this option to the list of other -D JVM options for this property.
      As mentioned previously, these settings can vary, but must match whatever you used when setting up the Jakarta EE 9 CI server.

  2. Install the Jakarta EE 9 CI and configure basic settings, as described in Chapter 4, "Installation."

  3. Start the Jakarta EE 9 CI application server.
    Refer to the application server documentation for complete instructions.

  4. Enable the Security Manager.
    If you are using the Jakarta EE 9 CI, execute the following command from the command line:

    asadmin create-jvm-options -Djava.security.manager
  5. Stop and restart your application server so it is running with the Security Manager enabled.

  6. Change to the <TS_HOME>/bin directory.

  7. Start your backend database.
    If you are using Derby as your backend database, execute the start.javadb Ant target:

    ant -f xml/impl/glassfish/s1as.xml start.javadb

    Otherwise, refer to your backend database administration documentation for information about starting your database server.

  8. Initialize your backend database.
    If you are using Derby as your backend database, execute the init.derby Ant target:

    ant -f xml/init.xml init.derby

    If you are not using Derby as your backend database, refer to Appendix C, "Configuring Your Backend Database."

    Note

    If you are using MySQL or MS SQL Server as your backend database, see Section 5.4.24, "Backend Database Setup," for additional database setup instructions.

  9. Run the configuration Ant target.

    ant config.vi
    Note

    By default, the config.vi Ant task configures the entire application server. Sometimes you may not want or need to configure everything, such as connector RAR files. If you are not performing connector-related tests, you can avoid the deployment and configuration of RAR files by using the Ant option -Dskip.config.connector=true. This will reduce configuration times, the deployment of unneeded RAR files, and the creation of unnecessary resources on the server under test. For example, the following command will do this.

    ant -Dskip.config.connector=true config.vi
  10. Build the special web services clients.
    The special webservices tests under the webservices12/specialcases directory have prebuilt endpoints, but the clients are not prebuilt. The clients will be built after the endpoints are first predeployed to the application server under test.
    During the build, the clients import the WSDLs (by means of the Jakarta EE wsimport and wsgen tools) from the predeployed webservices endpoints. This process verifies that importing a WSDL from a predeployed webservice endpoint works properly.
    To build the special webservices clients, the following command must be executed:

    ant build.special.webservices.clients

    This predeploys all the special webservices endpoints, builds all the special webservices clients, and then undeploys the special webservices endpoints. See Section 11.2.2, "Ant-Based Deployment Interface," for more information about the Ant-based deployment interface, including guidelines for creating your own Ant-based deployment implementation.

  11. Continue on to Chapter 7, "Executing Tests," for instructions on running tests.

5.3.3 Configuring Your Application Server as the VI

To use a Jakarta EE 9 server other than the Jakarta EE 9 CI, follow the steps below.

  1. Set server properties in your <TS_HOME>/bin/ts.jte file to suit your test environment.
    Be sure to set the following properties:

    1. Set the webServerHost property to the name of the host on which your Web server is running that is configured with the CI.
      The default setting is localhost.

    2. Set the webServerPort property to the port number of the host on which the Web server is running and configured with the CI.
      The default setting is 8001.

    3. Set the wsgen.ant.classname property to the Vendor’s implementation class that mimics the CI Ant task that in turn calls the wsgen Java-to-WSDL tool.
      The default setting is com.sun.tools.ws.ant.WsGen.

    4. Set the wsimport.ant.classname property to the Vendor’s implementation class that mimics the CI Ant task that in turn calls the wsimport WSDL-to-Java tool.
      The default setting is com.sun.tools.ws.ant.WsImport.

    5. Set the porting.ts.url.class property to your porting implementation class that is used for obtaining URLs.

    6. Set the database-related properties in the <TS_HOME>/bin/ts.jte file.
      Section C.3, "Database Properties in ts.jte," lists the names and descriptions for the database properties you need to set.

    7. Add the following JVM option to the command.testExecuteAppClient property to enable the Security Manager in the application client container:

      -Djava.security.manager

      Add this option to the list of other -D JVM options for this property.
      These settings can vary, but must match whatever you used when setting up your Jakarta Platform, Enterprise Edition server.

  2. Install the Jakarta Platform, Enterprise Edition VI and configure basic settings.
    If you want to configure your Jakarta Platform, Enterprise Edition server using Ant configuration target similar to the target for the Jakarta EE 9 CI, as described in Chapter 4, "Installation," you will need to modify the <TS_HOME>/bin/xml/javaee_vi.xml file to implement the defined Ant targets for your application server. Then run:

    ant config.vi

    The Ant configuration targets you implement, if any, may vary. Whichever configuration method you choose, make sure that all configuration steps in this procedure are completed as shown.

  3. Enable the Security Manager and then stop and restart your application server so it is running with the Security Manager enabled.

  4. Provide alternate endpoint and WSDL URLs, if necessary.
    The <TS_HOME>/bin directory contains the following .dat files:

    • jaxws-url-props.dat

    • jws-url-props.dat

    • webservices12-url-props.dat

      These files contain the webservice endpoint and WSDL URLs that the CTS tests use when running against the CI. In the porting package used by the TCK, the URLs are returned as is since this is the form that the CI expects. You may need an alternate form of these URLs to run the CTS tests in your environment. However, you MUST NOT modify the existing .dat files, but instead make any necessary changes in your own porting implementation class to transform the URLs appropriately for your environment.

  5. Install and configure a database for the server under test.

  6. Start your database.

  7. Initialize your database for TCK tests.

    1. If you choose to not implement the javaee_vi.xml targets, execute the following command to specify the appropriate DML file:
      (Derby DB Example)

      ant -Dtarget.dml.file=tssql.stmt \
      -Ddml.file=javadb/javadb.dml.sql copy.dml.file
    2. Execute the following command to initialize your particular database:

      ant -f <TS_HOME>/bin/xml/initdb.xml init.Database

      For example, to initialize a Derby DB database:

      ant -f <TS_HOME>/bin/xml/initdb.xml init.javadb

      Refer to Appendix C, "Configuring Your Backend Database," for detailed database configuration and initialization instructions and a list of database-specific initialization targets.

  8. Start your Jakarta EE 9 server.

  9. Set up required users and passwords.

    1. Set up database users and passwords that are used for JDBC connections.
      The Jakarta EE 9 Platform TCK requires several user names, passwords, and user-to-role mappings. These need to match those set in your ts.jte file. By default, user1, user2, user3, password1, password2, and password3 are set to cts1.

    2. Set up users and passwords for your Jakarta Platform, Enterprise Edition server.
      For the purpose of running the TCK test suite, these should be set as follows:

      User Password Groups

      j2ee_vi

      j2ee_vi

      staff

      javajoe

      javajoe

      guest

      j2ee

      j2ee

      staff, mgr, asadmin

      j2ee_ri

      j2ee_ri

      staff

      Note that adding the asadmin group is only necessary when running against the Eclipse GlassFish 6.0 Jakarta EE 9 CI application server. It is required in this case because the management Jakarta Enterprise Bean (MEjb) in the Jakarta EE 9 server is protected with the asadmin group. Other appservers may or may not choose to protect their MEjb. If necessary for your appserver implementation, you should also add the group name with which your MEjb is protected.
      Also make sure the principal to role-mappings that are specified in the runtime XML files are properly mapped in your environment (TODO: confirm that we can also delete mention of principal (user) ⇒ role-mappings). Note that the principal-to-role mappings may vary for each application.

  10. Make sure that the appropriate JDBC 4.1-compliant database driver class, any associated database driver native libraries, and the correct database driver URL are available.

  11. Configure your Jakarta Platform, Enterprise Edition server to use the appropriate JDBC logical name (jdbc/DB1) when accessing your database server.

  12. Configure your Jakarta EE 9 server to use the appropriate logical name (jdbc/DBTimer) when accessing your Jakarta Enterprise Beans timer.

  13. Provide access to a JNDI lookup service.

  14. Provide access to a Web server.

  15. Provide access to a Jakarta Mail server that supports the SMTP protocol.

  16. Execute the add.interop.certs Ant target.

    Note

    This step installs server side certificates for interoperability testing; that is, it installs the CI’s server certificate to VI and VI’s server certificate into the CI. This step is necessary for mutual authentication tests in which both the server and client authenticate to each other.

  17. Install the client-side certificate in the trustStore on the Jakarta EE 9 server.
    Certificates are located <TS_HOME>/bin/certificates. Use the certificate that suits your environment.

    1. cts_cert: For importing the TCK client certificate into a truststore

    2. clientcert.jks: Used by the Java SE 8 runtime to identify the CTS client’s identity

    3. clientcert.p12: Contains TCK client certificate in pkcs12 format

    4. Append the file <TS_HOME>/bin/server_policy.append to the Java policy file or files on your Jakarta EE 9 server.
      This file contains the grant statements used by the test harness, signature tests, and API tests.

    5. Append the file <TS_HOME>/bin/client_policy.append to the application client’s Java policy file, which is referenced in the TestExecuteAppClient section of the ts.jte file.

    6. Make the appropriate transaction interoperability setting on the Jakarta EE 9 server and the server that is running the Jakarta EE 9 CI.

    7. If necessary, refer to the sections later in this chapter for additional configuration information you may require for your particular test goals.

    8. Restart your Jakarta EE 9 server.

    9. Build the special Web services clients.
      This step may be bypassed at this time if you are not going to immediately run the tests under <TS_HOME>/src/com/sun/ts/tests/webservices12. However, you must return to this configuration section and complete it in order to run these tests.
      The special Web services tests under the webservices12/specialcases directory have prebuilt endpoints, but the clients are not prebuilt. The clients will be built after the endpoints are first predeployed to the application server under test.
      During the build the clients import the WSDLs (by means of the Jakarta EE wsimport and wsgen tools) from the predeployed Web services endpoints. This process verifies that importing a WSDL from a predeployed Web service endpoint works properly.

    10. Install the Jakarta EE 9 CI.

    11. Set the following properties in your <TS_HOME>/bin/ts.jte file.
      The current values should be saved since they will be needed later in this step.

      • Set the javaee.home.ri property to the location where the Jakarta EE 9 CI is installed.

      • Set the wsgen.ant.classname property to the Jakarta EE 9 application server Ant task that in turn calls the wsimport Java-to-WSDL tool. It must be set to:

        com.sun.tools.ws.ant.WsGen
      • Set the wsgen.classpath property to:

        ${javaee.classes.ri}:${tools.jar}
      • Set the wsimport.ant.classname property to the Jakarta EE 9 application server Ant task that in turn calls the wsimport WSDL-to-Java tool.
        It must be set to com.sun.tools.ws.ant.WsImport

      • Set the wsimport.classpath property to the following value:

        ${javaee.classes.ri}:${tools.jar}
    12. Build the special Web services clients by executing the following command:

      ant build.special.webservices.clients

      This predeploys all the special Web services endpoints, builds all the special webservices clients, and then undeploys the special webservices endpoints. See Section 11.2.2, "Ant-Based Deployment Interface," for more information about the Ant-based deployment interface, including guidelines for creating your own Ant-based deployment implementation.

    13. Once this command completes successfully, the following ts.jte properties must be set back to their previous values:

      • wsgen.ant.classname

      • wsgen.classpath

      • wsimport.ant.classname

      • wsimport.classpath

    14. The following webservices12-url-props.dat properties must be set back to their original values:

      • specialcases.defaultserviceref.wsdlloc

      • specialcases.nameattrserviceref.wsdlloc

      • specialcases.providerserviceref.wsdlloc

  18. Continue on to Chapter 7, "Executing Tests".

5.4 Modifying Environment Settings for Specific Technology Tests

Before you can run any of the technology-specific Jakarta EE 9 Platform TCK tests, you must supply certain information that JavaTest needs to run the tests in your particular environment. This information exists in the <TS_HOME>/bin/ts.jte environment file. This file contains sets of name/value pairs that are used by the tests. You need to assign a valid value for your environment for all of the properties listed in the sections that follow.

Note

This section only discusses a small subset of the properties you can modify. Refer to the ts.jte file for information about the many other properties you may want to modify for your particular test environment.

This section includes the following topics:

5.4.1 Test Harness Setup

Verify that the following properties, which are used by the test harness, have been set in the <TS_HOME>/bin/ts.jte file:

harness.temp.directory=<TS_HOME>/tmp
harness.log.port=2000
harness.log.traceflag=[true | false]
deployment_host.1=<hostname>
deployment_host.2=<hostname>
porting.ts.deploy2.class.1=<vendor-deployment-class>
porting.ts.login.class.1=<vendor-login-class>
porting.ts.url.class.1=<vendor-url-class>
porting.ts.jms.class.1=<vendor-jms-class>
porting.ts.tsHttpsURLConnection.class.1=<vendor-HttpsURLConnection-class>
  • The harness.temp.directory property specifies a temporary directory that the harness creates and to which the TCK harness and tests write temporary files. The default setting should not need to be changed.

  • The harness.log.port property specifies the port that server components of the tests use to send logging output back to JavaTest. If the default port is not available on the machine running JavaTest, you must edit this property and set it to an available port. The default setting is 2000.

  • The harness.log.traceflag property is used to turn on or turn off verbose debugging output for the tests. The value of the property is set to false by default. Set the property to true to turn debugging on.

  • The deployment_host.1 and deployment_host.2 properties specify the systems where the vendor’s Jakarta Platform, Enterprise Edition server and the Jakarta Platform, Enterprise Edition CI server are running. By default, JavaTest will use the orb.host and orb.host.ri systems, which are set in the ts.jte file.

  • The porting class .1 and .2 property sets specify the class names of porting class implementations. By default, both property sets point to the Jakarta Platform, Enterprise Edition CI-specific classes. To run the interoperability tests, do not modify the .2 set. These properties should always point to the Jakarta Platform, Enterprise Edition CI classes. Modify the .1 set to point to implementations that work in your specific Jakarta Platform, Enterprise Edition environment.

  • The -Dcts.tmp option for the testExecute and testExecuteAppClient commands in the ts.jte file have been set. This Java option tells the test suite the location to which the test suite will write temporary files.

5.4.2 Windows-Specific Properties

When configuring the Jakarta EE 9 Platform TCK for the Windows environment, set the following properties in <TS_HOME>/bin/ts.jte:

  • pathsep to semicolon (pathsep=;)

  • s1as.applicationRoot to the drive on which you have installed CTS (for example, s1as.applicationRoot=C:)
    When installing in the Windows environment, the Jakarta Platform, Enterprise Edition CI, JDK, and TCK should all be installed on the same drive. If you must install these components on different drives, also change the ri.applicationRoot property in addition to the pathsep and s1as.applicationRoot properties; for example:

ri.applicationRoot=C:
Note

When configuring the CI and TCK for the Windows environment, never specify drive letters in any path properties in ts.jte.

5.4.3 Test Execution Command Setup

The test execution command properties are used by the test harness. By default, the ts.jte file defines a single command line for each of the commands that is used for both UNIX and Windows environments.

  • command.testExecute

  • command.testExecuteAppClient

  • command.testExecuteAppClient2

If these commands do not meet your needs, you can define separate entries for the UNIX and Windows environments. Edit either the ts_unix or ts_win32 test execution properties in the ts.jte file. For UNIX, these properties are:

  • env.ts_unix.command.testExecute

  • env.ts_unix.command.testExecuteAppClient

  • env.ts_unix.command.testExecuteAppClient2

For Windows, these properties are:

  • env.ts_win32.command.testExecute

  • env.ts_win32.command.testExecuteAppClient

  • env.ts_win32.command.testExecuteAppClient2

The testExecute property specifies the Java command that is used to execute individual tests from a standalone URL client. Tests in which the client directly invokes a web component (Jakarta Servlet or Jakarta Server Pages), use this command line since there is no application client container involved.

Note

The default settings are specific to the Jakarta Platform, Enterprise Edition CI. If you are not using the Jakarta Platform, Enterprise Edition CI, adjust these properties accordingly.

5.4.4 Jakarta Servlet Test Setup

Make sure that the following servlet properties have been set in the ts.jte file:

ServletClientThreads=[2X size of default servlet instance pool]
servlet_waittime=[number_of_milliseconds]
servlet_async_wait=[number_of_seconds]
logical.hostname.servlet=server
s1as.java.endorsed.dirs=${endorsed.dirs}${pathsep}${ts.home}/endorsedlib

The ServletClientThreads property configures the number of threads used by the client for the SingleThreadModel servlet test. If your container implementation supports pooling of SingleThreadModel servlets, set the value of the ServletClientThreads property to twice the value of the default servlet instance pool size. If your container implementation only maintains a single instance of a ServletClientThreads servlet, use the default value of 2.

The servlet_waittime property specifies the amount of time, in milliseconds, to wait between the time when the HttpSession is set to expire on the server and when the HttpSession actually expires on the client. This time is configurable to allow the servlet container enough time to completely invalidate the HttpSession. The default value is 10 milliseconds.

The test serverpush in Jakarta Servlet 5.0, uses httpclient, a new library in JDK9 which is backported to JDK8. There is a restriction on using httpclient in JDK8 as the httpclient depends on java.util.concurrent.flow which is a new class in JDK9. To run the test on JDK8, use Java Endorsed Standards Override Mechanism and append the flow.jar into bootstrap classpath. This is done by appending the <TS_HOME>/endorsedlib directory to s1as.java.endorsed.dirs property in ts.jte.

The servlet_async_wait property sets the duration of time in seconds to wait between sending asynchronous messages. This property is used in place to test non-interrupted IO, where two messages are sent in two different batches and the receiving end will be read in a different read cycle. This property sets the time to wait in seconds on the sending side. The default is 4 seconds.

The logical.hostname.servlet property identifies the configuration name of the logical host on which the ServletContext is deployed. This used to identify the name of a logical host that processes Jakarta EE 9 requests. Jakarta EE 9 requests may be directed to a logical host using various physical or virtual host names or addresses, and a message processing runtime may be composed of multiple logical hosts. The logical.hostname.servlet property is required to properly identify the Jakarta EE 9 profile’s AppContextId hostname. This property is used by the Jakarta EE 9 security tests as well as by the ServletContext.getVirtualServerName() method. If a logical.hostname.servlet does not exist, set this property to the default hostname (for example, webServerHost). The default is "server".

5.4.5 Jakarta WebSocket Test Setup

Make sure that the following WebSocket property has been set in the ts.jte file:

ws_wait=[number_of_seconds]

The ws_wait property configures the wait time, in seconds, for the socket to send or receive a message. A multiple of 5 of this time is also used to test socket timeouts.

The Jakarta WebSocket tests also use the following properties: webServerHost and webServerPort. See Section 5.3.2, "Configuring the Jakarta EE 9 CI as the VI," for more information about setting these properties.

Note

The SSL related tests under /ts/javaeetck/src/com/sun/ts/tests/websocket/platform/jakarta/websocket/server/handshakerequest/authenticatedssl/ use self signed certificate bundled with the TCK bundle. These certificates are generated with localhost as the hostname and would work only when orb.host value is set to localhost in ts.jte. If the server’s hostname is used instead of the localhost, the tests in this suite might fail with the below exception - jakarta.websocket.DeploymentException: SSL handshake has failed.

5.4.6 JDBC Test Setup

The JDBC tests require you to set the timezone by modifying the tz property in the ts.jte file. On Solaris systems, you can check the timezone setting by looking in the file /etc/default/init. Valid values for the tz property are in the directory /usr/share/lib/zoneinfo. The default setting is US/Eastern. This setting is in /usr/share/lib/zoneinfo/US.

Note

The tz property is only used for Solaris configurations; it does not apply to Windows XP/2000.

5.4.7 Jakarta Mail Test Setup

Complete the following tasks before you run the Jakarta Mail tests:

  1. Set the following properties in the ts.jte file:

    mailuser1=[user@domain]
    mailFrom=[user@domain]
    mailHost=mailserver
    javamail.password=password
    • Set the mailuser1 property to a valid mail address. Mail messages generated by the Jakarta Mail tests are sent to the specified address. This user must be created in the IMAP server.

    • Set the mailFrom property to a mail address from which mail messages that the Jakarta Mail tests generate will be sent.

    • Set the mailHost property to the address of a valid mail server where the mail will be sent.

    • Set the javamail.password property to the password for mailuser1.

  2. Populate your IMAP server with sample messages.
    Change to the <TS_HOME>/bin directory and execute the Ant target populateMailbox to create the sample messages in your IMAP server.

    cd <TS_HOME>/bin
    ant populateMailbox

5.4.8 Jakarta RESTful Web Services Test Setup

This section explains how to set up the test environment to run the Jakarta RESTful Web Services tests using the Jakarta EE 9 Compatible Implementation and/or a Vendor Implementation. This setup also includes steps for packaging/repackaging and publishing the packaged/repackaged WAR files as well.

5.4.8.1 To Configure Your Environment to Run the Jakarta RESTful Web Services Tests Against the Jakarta EE 9 CI

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

  1. Set the jaxrs_impl_lib property to point to the Jakarta RESTful Web Services CI.
    The default setting for this property is ${javaee.home}/modules/jersey-container-servlet-core.jar .

  2. Set the servlet_adaptor property to point to the Servlet adapter class for the Jakarta RESTful Web Services implementation.
    The default setting for this property is org/glassfish/jersey/servlet/ServletContainer.class, the servlet adaptor supplied in Jersey.

  3. Set the jaxrs_impl_name property to the name of the Jakarta RESTful Web Services CI.
    The default setting for this property is jersey.
    An Ant script, jersey.xml, in the <TS_HOME>/bin/xml/impl/glassfish directory contains packaging instructions.

5.4.8.2 To Package WAR files for Deployment on the Jakarta EE 9 CI

The Jakarta EE 9 Platform TCK test suite does not come with prebuilt test WAR files for deployment on Jakarta EE 9 CI. The test suite includes a command to generate the test WAR files that will be deployed on the Jakarta EE 9 CI. The WAR files are Jersey-specific, with Jersey’s servlet class and Eclipse Jersey’s servlet defined in the web.xml deployment descriptor.

To package the Jakarta RESTful Web Services WAR files for deployment on the Jakarta EE 9 CI, complete the following steps:

  1. Change to the <TS_HOME>/bin directory.

  2. Execute the update.jaxrs.wars Ant target.
    In a test WAR files that has the servlet_adaptor property defined, this target replaces the servlet_adaptor value of the servlet class name property in the web.xml file of the WAR files to be deployed on the Jakarta EE 9 CI.

5.4.8.3 To Configure Your Environment to Run the Jakarta RESTful Web Services Tests Against a Vendor Implementation

Complete the following steps to configure your test environment to run the Jakarta RESTful Web Services tests against your vendor implementation. Before you can run the tests, you need to repackage the WAR files that contain the Jakarta RESTful Web Services tests and the VI-specific Servlet class that will be deployed on the vendor’s Jakarta EE 9-compliant application server.

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

  1. Set the jaxrs_impl_lib property to point to the JAR file that contains the vendor’s Jakarta RESTful Web Services Servlet adapter implementation.
    The default setting for this property is ${javaee.home}/modules/jersey-container-servlet-core.jar .

  2. Set the servlet_adaptor property to point to the Servlet adapter class for the vendor’s Jakarta RESTful Web Services implementation.
    The class must be located in the JAR file defined by the jaxrs_impl_lib property. By default, this property is set to org/glassfish/jersey/servlet/ServletContainer.class, the servlet adapter supplied in Jersey.

  3. Set the jaxrs_impl_name property to the name of the Jakarta RESTful Web Services vendor implementation to be tested.
    The name of the property must be unique. An Ant file bearing this name, <jaxrs_impl_name>.xml, should be created under <TS_HOME>/bin/xml/impl/${impl.vi} with packaging and/or deployment instructions as described in Section 5.4.9.4, "To Repackage WAR files for Deployment on the Vendor Implementation."
    The default setting for this property is jersey.

5.4.8.4 To Repackage WAR files for Deployment on the Vendor Implementation

To run the Jakarta RESTful Web Services tests against a vendor’s implementation in a Jakarta EE 8-compliant application server, the tests need to be repackaged to include the VI-specific servlet, and the VI-specific servlet must be defined in the deployment descriptor.

A vendor must create VI-specific Jakarta EE 9-compliant WAR files so the VI-specific Servlet class will be included instead of the Jakarta EE 9 CI-specific Servlet class.

All resource and application class files are already compiled. The Vendor needs to package these files. Jakarta EE 9 Platform TCK makes this task easier by including template WAR files that contain all of the necessary files except for the VI-specific servlet adaptor class. The Jakarta EE 9 TCK also provides a tool to help with the repackaging task.

Each test that has a Jakarta RESTful Web Services resource class to publish comes with a template deployment descriptor file. For example, the file <TS_HOME>/src/com/sun/ts/tests/jaxrs/ee/rs/get/web.xml.template contains the following elements:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" \
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" \
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee \
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
    <servlet>
        <servlet-name>CTSJAX-RSGET</servlet-name>
        <servlet-class>servlet_adaptor</servlet-class>
        <init-param>
            <param-name>jakarta.ws.rs.Application</param-name>
            <param-value>com.sun.ts.tests.jaxrs.ee.rs.get.TSAppConfig</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>CTSJAX-RSGET</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>
</web-app>

In this example, the <servlet-class> element has a value of servlet_adaptor, which is a placeholder for the implementation-specific Servlet class. An Eclipse Jersey-specific deployment descriptor also comes with the Jakarta EE 9 CI, Eclipse GlassFish 6.0, and has the values for the com.sun.jersey.spi.container.servlet.ServletContainer:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" \
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" \
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee \
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
   <servlet>
        <servlet-name>CTSJAX-RSGET</servlet-name>
        <servlet-class>
        org.glassfish.jersey.servlet.ServletContainer
        </servlet-class>
        <init-param>
            <param-name>jakarta.ws.rs.Application</param-name>
            <param-value>com.sun.ts.tests.jaxrs.ee.rs.get.TSAppConfig</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>CTSJAX-RSGET</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>30</session-timeout>
        </session-config>
</web-app>

The Jakarta EE 9 Platform TCK test suite provides a tool, ${ts.home}/bin/xml/impl/glassfish/jersey.xml, for the Jakarta EE 9 CI that you can use as a model to help you create your own VI-specific Web test application.

The following steps explain how to create a VI-specific deployment descriptor.

  1. Create a VI handler file.
    Create a VI-specific handler file <TS_HOME>/bin/xml/impl/${impl.vi}/${jaxrs_impl_name}.xml if one does not already exist.
    Ensure that the jaxrs_impl_name property is set in the ts.jte file and that its name is unique, to prevent another file with the same name from being overwritten.

  2. Set the servlet_adaptor property in the ts.jte file.
    This property will be used to set the value of the <servlet-class> element in the deployment descriptor.

  3. Create VI Ant tasks.
    Create a update.jaxrs.wars target in the VI handler file. Reference this update.jaxrs.wars target in the jersey.xml file.
    This target will create a web.xml.${jaxrs_impl_name} for each test that has a deployment descriptor template. The web.xml.${jaxrs_impl_name) will contain the VI-specific Servlet class name. It will also create the test WAR files will be created under the <TS_HOME>/dist directory. For example:

    cd $TS_HOME/dist/com/sun/ts/tests/jaxrs/ee/rs/get/
    ls jaxrs_rs_get_web.war.jersey
    jaxrs_rs_get_web.war.${jaxrs_impl_name}
  4. Change to the <TS_HOME>/bin directory and execute the update.jaxrs.wars Ant target.
    This creates a web.xml.${jaxrs_impl_name} file for each test based on the VI’s servlet class name and repackages the tests.

5.4.9 Jakarta Connector Test Setup

The Jakarta Connector tests verify that a Jakarta EE 9 server correctly implements the Jakarta Connector V1.7 specification. The Connector compatibility tests ensure that your Jakarta EE 9 server still supports the Connector V1.0 functionality.

The config.vi target is run to configure the Jakarta EE 9 server for running Connector tests. The config.vi target calls the config.connecto`r target, which is defined in `TS_HOME/bin/xml/impl/glassfish/s1as.xml, to deploy the RAR files listed in Section 5.4.10.1, "Extension Libraries." and create the required connection resources and connection pools used for the Connector tests. The config.vi target also performs several other tasks, such as creating required users and security mappings, setting appropriate JVM options, etc. that also are needed to run the Connector tests.

5.4.9.1 Extension Libraries

The following Connector files are deployed as part of the config.vi Ant target:

  • whitebox-mixedmode.rar

  • whitebox-tx-param.rar

  • whitebox-multianno.rar

  • whitebox-tx.rar

  • whitebox-anno_no_md.rar

  • whitebox-notx-param.rar

  • whitebox-xa-param.rar

  • whitebox-mdcomplete.rar

  • whitebox-notx.rar

  • whitebox-xa.rar

  • old-dd-whitebox-notx-param.rar

  • old-dd-whitebox-xa-param.rar

  • old-dd-whitebox-tx.rar

  • old-dd-whitebox-notx.rar

  • old-dd-whitebox-xa.rar

  • old-dd-whitebox-tx-param.rar

Note

RAR files with an old prefix are used to test the support of RAs that are bundled with an older version of the ra.xml files.

The manifest file in each RAR file includes a reference to the whitebox extension library. The whitebox.jar file is a Shared Library that must be deployed as a separate entity that all the Jakarta Connector RAR files access. This extension library is needed to address classloading issues.

The RAR files that are used with Jakarta EE 9 Platform TCK test suite differ from those that were used in earlier test suites. Jakarta EE 9 Platform TCK no longer bundles the same common classes into every RAR file. Duplicate common classes have been removed and now exist in the whitebox.jar file, an Installed Library that is deployed and is made available before any other RAR files are deployed.

This was done to address the following compatibility issues:

  • Portable use of Installed Libraries for specifying a resource adapter’s shared libraries
    See section EE.8.2.2 of the Jakarta EE 9 platform specification and section 20.2.0.1 in the Jakarta Connectors (formerly JCA) 1.7 specification, which explicitly state that the resource adapter server may employ the library mechanisms in Jakarta EE 9.

  • Support application-based standalone connector accessibility
    Section 20.2.0.4 of the Jakarta Connectors (formerly JCA) 1.7 Specification uses the classloading requirements that are listed in section 20.3 in the specification.

5.4.9.2 Connector Resource Adapters and Classloading

Jakarta EE 9 Platform TCK has scenarios in which multiple standalone RAR files that use the same shared library (for example, whitebox.jar) are referenced from an application component.

Each standalone RAR file gets loaded in its own classloader. Since the application component refers to more than one standalone RAR file, all of the referenced standalone RAR files need to be made available in the classpath of the application component. In versions of the TCK prior to Java EE 5, since each standalone RAR file contained a copy of the whitebox.jar file, every time there was a reference to a class in the whitebox.jar file from a standalone RAR, the reference was resolved by using the private version of whitebox.jar (the whitebox.jar file was bundled in each standalone RAR file). This approach can lead to class type inconsistency issues.

5.4.9.3 Use Case Problem Scenario

Assume that RAR1 and RAR2 are standalone RAR files that are referred to by an application, where:

  • RAR1’s classloader has access to RAR1’s classes and its copy of whitebox.jar. (RAR1’s classloader contains RAR1’s classes and whitebox.jar)

  • RAR2’s classloader has access to RAR2’s classes and its copy of whitebox.jar. (RAR2’s classloader contains RAR2’s classes and whitebox.jar)

When the application refers to both of these RAR files, a classloader that encompasses both of these classloaders (thereby creating a classloader search order) is provided to the application. The classloader search order could have the following sequence: ([RAR1’s Classloader: RAR1’s classes and whitebox.jar], [RAR2’s Classloader: RAR2’s classes and whitebox.jar]).

In this scenario, when an application loads a class (for example, class Foo) in whitebox.jar, the application gets class Foo from RAR1’s classloader because that is first in the classloader search order. However, when this is cast to a class (for example, Foo or a subclass of Foo or even a class that references Foo) that is obtained from RAR2’s classloader (a sequence that is typically realized in a ConnectionFactory lookup), this would result in a class-cast exception.

The portable way of solving the issues raised by this use case problem scenario is to use installed libraries, as described in section EE.8.2.2 in the Jakarta EE 9 platform specification. If both RAR files (RAR1 and RAR2) reference whitebox.jar as an installed library and the application server can use a single classloader to load this common dependency, there will be no type-related issues.

In the CI Eclipse GlassFish 6.0, domain-dir/lib/applibs is used as the Installed Library directory and is the location to which the whitebox.jar file gets copied.

5.4.9.4 Required Porting Package

The Jakarta EE 9 Platform TCK test suite treats the whitebox.jar dependency as an Installed Library dependency instead of bundling the dependency (or dependencies) with every RAR file. Each RAR file now contains a reference to the whitebox.jar file through its Manifest files Extension-List attribute.

It is necessary to identify the whitebox.jar to the connector server as an installed library. The mechanism used to identify the whitebox.jar file to the connector server as an Installed Library must allow the Installed Libraries to have dependencies on Jakarta EE APIs. In other words, because the whitebox.jar file depends on Jakarta EE APIs, one cannot simply put the whitebox.jar file into a java.ext.dir directory , which gets loaded by the VM extension classloader, because that mechanism does not allow the whitebox.jar file to support its dependencies on the Jakarta EE APIs. For this reason, the Installed Library must support access to the Jakarta EE APIs.

See section EE.8.2.2 in the Jakarta EE 9 platform specification for information about the compatible implementation’s support for Installed libraries. However, note that this section does not recommend a mechanism that a deployer can use to provide Installed Libraries in a portable manner.

5.4.9.5 Creating Security Mappings for the Connector RAR Files

The Ant target create.security.eis.mappings in the <TS_HOME>/bin/xml/impl/glassfish/connector.xml file maps Resource Adapter user information to existing user information in the CI.

For the Eclipse GlassFish 6.0 CI, these mappings add a line to the domain.xml file, similar to the one shown below, and should include 6 of these mappings:

<jvm-options>-Dwhitebox-tx-map=cts1=j2ee</jvm-options>
<jvm-options>-Dwhitebox-tx-param-map=cts1=j2ee</jvm-options>
<jvm-options>-Dwhitebox-notx-map=cts1=j2ee</jvm-options>
<jvm-options>-Dwhitebox-notx-param-map=cts1=j2ee</jvm-options>
<jvm-options>-Dwhitebox-xa-map=cts1=j2ee</jvm-options>
<jvm-options>-Dwhitebox-xa-param-map=cts1=j2ee</jvm-options>

If the rauser1 property has been set to cts1 and the user property has been set to j2ee in the ts.jte file, the following mappings would be required in the connector runtime:

  • For RA whitebox-tx, map cts1 to j2ee

  • For RA whitebox-tx-param, map cts1 to j2ee

  • For RA whitebox-notx, map cts1 to j2ee

  • For RA whitebox-notx-param, map cts1 to j2ee

  • For RA whitebox-xa, map cts1 to j2ee

  • For RA whitebox-xa-param, map cts1 to j2ee

5.4.9.6 Creating Required Server-Side JVM Options

Create the required JVM options that enable user information to be set and/or passed from the ts.jte file to the server. The RAR files use some of the property settings in the ts.jte file.

To see some of the required JVM options for the server under test, see the s1as.jvm.options property in the ts.jte file. The connector tests require that the following subset of JVM options be set in the server under test:

-Dj2eelogin.name=j2ee
-Dj2eelogin.password=j2ee
-Deislogin.name=cts1
-Deislogin.password=cts1

5.4.10 XA Test Setup

The XA Test setup requires that the ejb_Tsr.ear file be deployed as part of the config.vi Ant target. The ejb_Tsr.ear file contains an embedded RAR file, which requires the creation of a connection-pool and a connector resource.

For more details about the deployment of ejb_Tsr.ear and its corresponding connection pool and connector resource values, see the setup.tsr.embedded.rar Ant target in the <TS_HOME>/bin/xml/impl/glassfish/s1as.xml file.

The XA tests reference some JDBCWhitebox name bindings that are created as part of the config.vi target but those name bindings are not tied to any JDBC RAR files. Instead, the following XA-specific connection pool ids are referenced by the XA tests:

  • eis/JDBCwhitebox-xa

  • eis/JDBCwhitebox-tx

  • eis/JDBCwhitebox-notx

For more details on these JDBC resources, examine the add.jdbc.resources target in the same file to see the required JDBC resources that are created. Both targets are called as part of the config.vi target.

Complete the following steps (create JDBC connection pools and JDBC resource elements, deploy the RAR files) to set up your environment to run the XA tests:

  1. Create a JDBC connection pool with the following attributes:

    • Set the resource type to javax.sql.XADataSource

    • Set the datasourceclassname to org.apache.derby.jdbc.EmbeddedXADataSource

    • Set the property to DatabaseName=<Derby-location>:user=cts1:password=cts1

    • Set the connection pool name to cts-derby-XA-pool
      For example, you could use the asadmin command line utility in the Jakarta EE 9 CI, Eclipse GlassFish 6.0 to create this connection pool:

      asadmin create-jdbc-connection-pool --restype javax.sql.XADataSource \
      --datasourceclassname org.apache.derby.jdbc.EmbeddedXADataSource  \
      --property 'DatabaseName=/tmp/DerbyDB:user=cts1:password=cts1' \
      cts-derby-XA-pool

      See the add.jdbc.pools Ant target in the s1as.xml file for additional information.

  2. Create three JDBC connection pool elements (more specifically, the JDBC connection pool elements) with the following JNDI names:

    • For the first connection pool element, set the connection pool id to cts-derby-XA-pool and the JNDI name to eis/JDBCwhitebox-xa

    • For the second connection pool element, set the connection pool id to cts-derby-XA-pool and the JNDI name to eis/JDBCwhitebox-tx

    • For the third connection pool element, set the connection pool id to cts-derby-XA-pool and the JNDI name to eis/JDBCwhitebox-notx
      For example, you could use the asadmin command line utility in the Jakarta EE 9 CI to create the three connection pool elements:

      asadmin  asadmin  create-jdbc-resource --connectionpoolid cts-derby-XA-pool \
       eis/JDBCwhitebox-xa
      asadmin  create-jdbc-resource --connectionpoolid cts-derby-XA-pool \
       eis/JDBCwhitebox-tx
      asadmin  create-jdbc-resource --connectionpoolid cts-derby-XA-pool \
       eis/JDBCwhitebox-notx

      If two or more JDBC resource elements point to the same connection pool element, they use the same pool connection at runtime. Jakarta EE 9 Platform TCK does reuse the same connection pool ID for testing the Jakarta EE 9 CI Eclipse GlassFish 6.0.

  3. Make sure that the following EIS and RAR files have been deployed into your environment before you run the XA tests:

    • For the EIS resource adapter, deploy the following RAR files. Most of these files are standalone RAR files, but there is also an embedded RAR file that is contained in the ejb_Tsr.ear file. With the CI, these RAR files are deployed as part of the config.vi Ant task. The following RAR files are defined in the ts.jte file.

      whitebox-tx=java:comp/env/eis/whitebox-tx
      whitebox-notx=java:comp/env/eis/whitebox-notx
      whitebox-xa=java:comp/env/eis/whitebox-xa
      whitebox-tx-param=java:comp/env/eis/whitebox-tx-param
      whitebox-notx-param=java:comp/env/eis/whitebox-notx-param
      whitebox-xa-param=java:comp/env/eis/whitebox-xa-param
      whitebox-embed-xa=
      "__SYSTEM/resource/ejb_Tsr#whitebox-xa#com.sun.ts.tests.common.connector.whitebox.TSConnectionFactory"
    • The embedded RAR files are located in the <TS_HOME>/src/com/sun/ts/tests/xa/ee/tsr directory.

    • The EIS RAR files are located in the following directory: <TS_HOME>/src/com/sun/ts/tests/common/connector/whitebox
      RAR files in the <TS_HOME>/src/com/sun/ts/tests/common/connector directory must be built before any dependent tests can pass. Deployment can either be done ahead of time or at runtime, as long as connection pools and resources are established prior to test execution.
      The XA tests make use of existing connector RAR files, which typically get deployed when the config.vi Ant task is run. Note that there are currently no JDBCwhitebox source files and no JDNCwhitebox RAR files.

5.4.11 Jakarta Enterprise Beans 4.0 Test Setup

This section explains special configuration that needs to be completed before running the Jakarta Enterprise Beans 4.0 DataSource and Stateful Timeout tests.

The Jakarta Enterprise Beans 4.0 DataSource tests do not test XA capability and XA support in a database product is typically not required for these tests. However, some Jakarta EE products could be implemented in such a way that XA must be supported by the database. For example, when processing the @DataSourceDefinition annotation or <data-source> descriptor elements in tests, a Jakarta EE product infers the datasource type from the interface implemented by the driver class. When the driver class implements multiple interfaces, such as javax.sql.DataSource, javax.sql.ConnectionPoolDataSource, or javax.sql.XADataSource, the vendor must choose which datasource type to use. If javax.sql.XADataSource is chosen, the target datasource system must be configured to support XA. Consult the documentation for your database system and JDBC driver for information that explains how to enable XA support.

5.4.11.1 To Configure the Test Environment to Run the Jakarta Enterprise Beans 4.0 DataSource Tests

The EJB 3.2 DataSource tests under the following tests/ejb30 directories require you to run the Ant task in Step 2.

  • com/sun/ts/tests/ejb30/lite/packaging/war/datasource

  • com/sun/ts/tests/ejb30/misc/datasource

  • com/sun/ts/tests/ejb30/assembly/appres

If your database vendor requires you to set any vendor-specific or less common DataSource properties, complete step 1 and then complete step 2, as explained below.

  1. Set any vendor-specific or less common datasource properties with the jdbc.datasource.props property in the ts.jte file.
    The value of the property is a comma-separated array of name-value pairs, in which each property pair uses a "name=value" format, including the surrounding double quotes.
    The value of the property must not contain any extra spaces.
    For example:

    jdbc.datasource.props="driverType=thin","name2=vale2"
  2. Run the configure.datasource.tests Ant target to rebuild the Jakarta Enterprise Beans 4.0 DataSource Definition tests using the new database settings specified in the ts.jte file.
    This step must be completed for Jakarta EE 9 and Jakarta EE 9 Web Profile testing.

5.4.11.2 To Configure the Test Environment to Run the Jakarta Enterprise Beans 4.0 Stateful Timeout Tests

The Jakarta Enterprise Beans 4.0 Stateful Timeout Tests in the following test directories require special setup:

  • com/sun/ts/tests/ejb30/lite/stateful/timeout

  • com/sun/ts/tests/ejb30/bb/session/stateful/timeout

    1. Set the javatest.timeout.factor property in the ts.jte file to a value such that the JavaTest harness does not time out before the test completes.
      A value of 2.0 or greater should be sufficient.

    2. Set the test.ejb.stateful.timeout.wait.seconds property, which specifies the minimum amount of time, in seconds, that the test client waits before verifying the status of the target stateful bean, to a value that is appropriate for your server.
      The value of this property must be an integer number. The default value is 480 seconds. This value can be set to a smaller number (for example, 240 seconds) to speed up testing, depending on the stateful timeout implementation strategy in the target server.

5.4.12 Jakarta Enterprise Beans Timer Test Setup

Set the following properties in the ts.jte file to configure the Jakarta Enterprise Beans timer tests:

ejb_timeout=[interval_in_milliseconds]
ejb_wait=[interval_in_milliseconds]
  • The ejb_timeout property sets the duration of single-event and interval timers. The default setting and recommended minimum value is 30000 milliseconds.

  • The ejb_wait property sets the period for the test client to wait for results from the ejbTimeout() method. The default setting and recommended minimum value is 60000 milliseconds.

Jakarta EE 9 Platform TCK does not have a property that you can set to configure the date for date timers.

The timer tests use the specific jndi-name jdbc`/DBTimer` for the datasource used for container-managed persistence to support the use of an XA datasource in the Jakarta EE 9 timer implementation. For example:

<jdbc-resource enabled="true" jndi-name="jdbc/DBTimer"
               object-type="user" pool-name="cts-javadb-XA-pool" />

The test directories that use this datasource are:

ejb/ee/timer
ejb/ee/bb/entity/bmp/allowedmethostest
ejb/ee/bb/entity/cmp20/allowedmethodstest

When testing against the Jakarta Platform, Enterprise Edition CI, Eclipse GlassFish 6.0, you must first start the Derby DB and initialize it in addition to any other database you may be using, as explained in Configuring the Jakarta EE 9 CI as the VI.

5.4.13 Entity Bean Container-Managed Persistence Test Setup for Jakarta Enterprise Beans V 1.1

Your Jakarta Platform, Enterprise Edition implementation should map the following instance variables to a backend datastore. These are needed to run the TCK entity bean container-managed persistence (cmp1.1) tests.

The Jakarta Platform, Enterprise Edition CI creates the table used by container-managed persistence by appending "Table" to the bean name. For example, if your bean name is TestEJB, the table that will be created will be TestEJBTable.

The container-managed fields for most cmp tests must have the following names and the following Java types:

Column Name Java Type

key_id

Integer

brand_name

String

price

Float

These instance variable names correspond to the following database schema:

KEY_ID (INTEGER NOT NULL)
BRAND_NAME (VARCHAR(32))
PRICE (FLOAT)
PRIMARY KEY (KEY_ID)

These instance variables are used in the transactional entity test bean for the transactional test cases (tx) and in the database support utility class for the bean behavior test cases (bb). These instance variables, used in the enterprise bean tests, must be accessible at deployment time.

The Jakarta Platform, Enterprise Edition CI, Eclipse GlassFish 6.0 provides the container-managed persistence implementation-specific features as part of its runtime XML file. Your Jakarta Platform, Enterprise Edition platform implementation needs to map the container-managed fields to the appropriate backend datastore. The manner in which you do this is implementation-specific. The DeploymentInfo class provides all of the runtime XML information as an object that is passed to the TSDeploymentInterface implementation.

For a list of SQL statements used in CMP 1.1 finders, refer to SQL Statements for CMP 1.1 Finders.

5.4.14 Jakarta Persistence API Test Setup

The Jakarta Persistence API tests exercise the requirements as defined in the Jakarta Persistence API Specification. This specification defines a persistence context to be a set of managed entity instances, in which for any persistent identity there is a unique entity instance. Within the persistence context, the entity instances and their life cycles are managed by the entity manager.

Within a Jakarta Platform, Enterprise Edition environment, support for both container-managed and application-managed entity managers is required. Application-managed entity managers can be Jakarta Transactions or resource-local. Refer to Chapter 7 of the Jakarta Persistence API Specification (https://jakarta.ee/specifications/persistence/3.0) for additional information regarding entity managers.

5.4.14.1 To Configure the Test Environment to Run the Jakarta Persistence Pluggability Tests

The Jakarta Persistence Pluggability tests under the src/com/sun/ts/tests/jpa/ee/pluggability directory ensure that a third-party persistence provider is pluggable, in nature.

After Java EE 7 TCK, the pluggability tests were rewritten to use a stubbed-out legacy JPA 2.1 implementation, which is located in the src/com/sun/ts/jpa/common/pluggibility/altprovider directory.

In Java EE 7 TCK, the Persistence API pluggability tests required special setup to run. This is no longer the case, since Jakarta EE 9 Platform TCK now enables the pluggability tests to be executed automatically along with all the other Persistence tests. The Jakarta Persistence tests have a new directory structure. In Java EE 7 TCK, the tests were in the src/com/sun/ts/tests/ejb30/persistence directory. The Jakarta EE 9 tests are now in the src/com/sun/ts/tests/jpa directory.

5.4.14.2 Enabling Second Level Caching Support

Jakarta Persistence supports the use of a second-level cache by the persistence provider. The ts.jte file provides a property that controls the TCK test suite’s use of the second-level cache.

The persistence.second.level.caching.supported property is used to determine if the persistence provider supports the use of a second-level cache. The default value is true. If your persistence provider does not support second level caching, set the value to false.

5.4.14.3 Persistence Test Vehicles

The persistence tests are run in a variety of "vehicles" from which the entity manager is obtained and the transaction type is defined for use. There are six vehicles used for these tests:

  • stateless3: Bean-managed stateless session bean using JNDI to lookup a Jakarta Transactions EntityManager; uses UserTransaction methods for transaction demarcation

  • stateful3: Container-managed stateful session bean using @PersistenceContext annotation to inject Jakarta Transactions EntityManager; uses container-managed transaction demarcation with a transaction attribute (required)

  • appmanaged: Container-managed stateful session bean using @PersistenceUnit annotation to inject an EntityManagerFactory; the EntityManagerFactory API is used to create an Application-Managed Jakarta Transactions EntityManager, and uses the container to demarcate transactions

  • appmanagedNoTx: Container-managed stateful session bean using @PersistenceUnit annotation to inject an EntityManagerFactory; the EntityManagerFactory API is used to create an Application-Managed Resource Local EntityManager, and uses the EntityTransaction APIs to control transactions

  • pmservlet: Servlet that uses the @PersistenceContext annotation at the class level and then uses JNDI lookup to obtain the EntityManager; alternative to declaring the persistence context dependency via a persistence-context-ref in web.xml and uses UserTransaction methods for transaction demarcation

  • puservlet: Servlet that injects an EntityManagerFactory using the @PersistenceUnit annotation to create a to Resource Local EntityManager, and uses EntityTransaction APIs for transaction demarcation

Note

For vehicles using a RESOURCE_LOCAL transaction type, be sure to configure a non-transactional resource with the logical name jdbc/DB_no_tx. Refer to the ts.jte file for information about the jdbc.db property.

5.4.14.4 GeneratedValue Annotation

The Jakarta Persistence API Specification also defines the requirements for the GeneratedValue annotation. The default for this annotation is GenerationType.AUTO. Per the specification, AUTO indicates that the persistence provider should pick an appropriate strategy for the particular database. The AUTO generation strategy may expect a database resource to exist, or it may attempt to create one.

The db.supports.sequence property is used to determine if a database supports the use of SEQUENCE. If it does not, this property should be set to false so the test is not run. The default value is true.

If the database under test is not one of the databases defined and supported by TCK, the user will need to create an entry similar to the one listed in Example 5-1.

Example 5-1 GeneratedValue Annotation Test Table
DROP TABLE SEQUENCE;
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(10), SEQ_COUNT INT, CONSTRAINT SEQUENCE_PK /
PRIMARY KEY (SEQ_NAME) );
INSERT into SEQUENCE(SEQ_NAME, SEQ_COUNT) values ('SEQ_GEN', 0) ;

You should add your own table to your chosen database DDL file provided prior to running these tests. The Data Model used to test the Jakarta Persistence Query Language can be found in Appendix D, "EJBQL Schema."

The persistence.xml file, which defines a persistence unit, contains the unitName CTS-EM for Jakarta Transactions entity managers. This corresponds to jta-data-source, jdbc/DB1, and to CTS-EM-NOTX for RESOURCE_LOCAL entity managers, which correspond to a non-jta-data-source jdbc/DB_no_tx.

5.4.15 Jakarta Messaging Test Setup

This section explains how to set up and configure the Jakarta EE 9 Platform TCK test suite before running the Jakarta Messaging tests.

Note

The client-specified values for JMSDeliveryMode, JMSExpiration, and JMSPriority must not be overridden when running the TCK Jakarta Messaging tests.

5.4.15.1 To Configure a Slow Running System

Make sure that the following property has been set in the ts.jte file:

jms_timeout=10000

This property specifies the length of time, in milliseconds, that a synchronous receive operation will wait for a message. The default value of the property should be sufficient for most environments. If, however, your system is running slowly and you are not receiving the messages that you should be, you need to increase the value of this parameter.

5.4.15.2 To Test Your Jakarta Messaging Resource Adapter

If your implementation supports Jakarta Messaging as a Resource Adapter, you must set the name of the jmsra.name property in the ts.jte file to the name of your Jakarta Messaging Resource Adapter. The default value for the property is the name of the Jakarta Messaging Resource Adapter in the Jakarta EE 9 CI.

If you modify the jmsra.name property, you must rebuild the Jakarta Messaging tests that use this property. You rebuild the tests by doing the following:

  1. Change to the TS_HOME/bin directory.

  2. Invoke the following Ant task:

    ant rebuild.jms.rebuildable.tests

    This rebuilds the tests under TS_HOME/src/com/sun/ts/tests/jms/ee20/resourcedefs.

5.4.15.3 To Create Jakarta Messaging Administered Objects

If you do not have an API to create Jakarta Messaging Administered objects, and you cannot create an Ant target equivalent to config.vi, you can use the list that follows and manually create the objects. If you decide to create these objects manually, you need to provide a dummy implementation of the Jakarta Messaging porting interface, TSJMSAdminInterface.

The list of objects you need to manually create includes the following factories, queues, and topics.

  • Factories:

    jms/TopicConnectionFactory
    jms/DURABLE_SUB_CONNECTION_FACTORY, clientId=cts
    jms/MDBTACCESSTEST_FACTORY, clientId=cts1
    jms/DURABLE_BMT_CONNECTION_FACTORY, clientId=cts2
    jms/DURABLE_CMT_CONNECTION_FACTORY, clientId=cts3
    jms/DURABLE_BMT_XCONNECTION_FACTORY, clientId=cts4
    jms/DURABLE_CMT_XCONNECTION_FACTORY, clientId=cts5
    jms/DURABLE_CMT_TXNS_XCONNECTION_FACTORY, clientId=cts6
    jms/QueueConnectionFactory
    jms/ConnectionFactory
  • Queues:

    MDB_QUEUE
    MDB_QUEUE_REPLY
    MY_QUEUE
    MY_QUEUE2
    Q2
    QUEUE_BMT
    ejb_ee_bb_localaccess_mdbqaccesstest_MDB_QUEUE
    ejb_ee_deploy_mdb_ejblink_casesensT_ReplyQueue
    ejb_ee_deploy_mdb_ejblink_casesens_ReplyQueue
    ejb_ee_deploy_mdb_ejblink_casesens_TestBean
    ejb_ee_deploy_mdb_ejblink_scopeT_ReplyQueue
    ejb_ee_deploy_mdb_ejblink_scope_ReplyQueue
    ejb_ee_deploy_mdb_ejblink_scope_TestBean
    ejb_ee_deploy_mdb_ejblink_singleT_ReplyQueue
    ejb_ee_deploy_mdb_ejblink_single_ReplyQueue
    ejb_ee_deploy_mdb_ejblink_single_TestBean
    ejb_ee_deploy_mdb_ejblink_single_TestBeanBMT
    ejb_ee_deploy_mdb_ejbref_casesensT_ReplyQueue
    ejb_ee_deploy_mdb_ejbref_casesens_ReplyQueue
    ejb_ee_deploy_mdb_ejbref_casesens_TestBean
    ejb_ee_deploy_mdb_ejbref_scopeT_ReplyQueue
    ejb_ee_deploy_mdb_ejbref_scope_Cyrano
    ejb_ee_deploy_mdb_ejbref_scope_ReplyQueue
    ejb_ee_deploy_mdb_ejbref_scope_Romeo
    ejb_ee_deploy_mdb_ejbref_scope_Tristan
    ejb_ee_deploy_mdb_ejbref_singleT_ReplyQueue
    ejb_ee_deploy_mdb_ejbref_single_ReplyQueue
    ejb_ee_deploy_mdb_ejbref_single_TestBean
    ejb_ee_deploy_mdb_ejbref_single_TestBeanBMT
    ejb_ee_deploy_mdb_enventry_casesensT_ReplyQueue
    ejb_ee_deploy_mdb_enventry_casesens_CaseBean
    ejb_ee_deploy_mdb_enventry_casesens_CaseBeanBMT
    ejb_ee_deploy_mdb_enventry_casesens_ReplyQueue
    ejb_ee_deploy_mdb_enventry_scopeT_ReplyQueue
    ejb_ee_deploy_mdb_enventry_scope_Bean1_MultiJar
    ejb_ee_deploy_mdb_enventry_scope_Bean1_SameJar
    ejb_ee_deploy_mdb_enventry_scope_Bean2_MultiJar
    ejb_ee_deploy_mdb_enventry_scope_Bean2_SameJar
    ejb_ee_deploy_mdb_enventry_scope_ReplyQueue
    ejb_ee_deploy_mdb_enventry_singleT_ReplyQueue
    ejb_ee_deploy_mdb_enventry_single_AllBean
    ejb_ee_deploy_mdb_enventry_single_AllBeanBMT
    ejb_ee_deploy_mdb_enventry_single_BooleanBean
    ejb_ee_deploy_mdb_enventry_single_ByteBean
    ejb_ee_deploy_mdb_enventry_single_DoubleBean
    ejb_ee_deploy_mdb_enventry_single_FloatBean
    ejb_ee_deploy_mdb_enventry_single_IntegerBean
    ejb_ee_deploy_mdb_enventry_single_LongBean
    ejb_ee_deploy_mdb_enventry_single_ReplyQueue
    ejb_ee_deploy_mdb_enventry_single_ShortBean
    ejb_ee_deploy_mdb_enventry_single_StringBean
    ejb_ee_deploy_mdb_resref_singleT_ReplyQueue
    ejb_ee_deploy_mdb_resref_single_ReplyQueue
    ejb_ee_deploy_mdb_resref_single_TestBean
    ejb_ee_sec_stateful_mdb_MDB_QUEUE
    ejb_sec_mdb_MDB_QUEUE_BMT
    ejb_sec_mdb_MDB_QUEUE_CMT
    jms_ee_mdb_mdb_exceptQ_MDB_QUEUETXNS_CMT
    jms_ee_mdb_mdb_exceptQ_MDB_QUEUE_BMT
    jms_ee_mdb_mdb_exceptQ_MDB_QUEUE_CMT
    jms_ee_mdb_mdb_exceptT_MDB_QUEUETXNS_CMT
    jms_ee_mdb_mdb_exceptT_MDB_QUEUE_BMT
    jms_ee_mdb_mdb_exceptT_MDB_QUEUE_CMT
    jms_ee_mdb_mdb_msgHdrQ_MDB_QUEUE
    jms_ee_mdb_mdb_msgPropsQ_MDB_QUEUE
    jms_ee_mdb_mdb_msgTypesQ1_MDB_QUEUE
    jms_ee_mdb_mdb_msgTypesQ2_MDB_QUEUE
    jms_ee_mdb_mdb_msgTypesQ3_MDB_QUEUE
    jms_ee_mdb_mdb_rec_MDB_QUEUE
    jms_ee_mdb_sndQ_MDB_QUEUE
    jms_ee_mdb_sndToQueue_MDB_QUEUE
    jms_ee_mdb_mdb_synchrec_MDB_QUEUE
    jms_ee_mdb_xa_MDB_QUEUE_BMT
    jms_ee_mdb_xa_MDB_QUEUE_CMT
    testQ0
    testQ1
    testQ2
    testQueue2
    fooQ
  • Topics:

    MY_TOPIC
    MY_TOPIC2
    TOPIC_BMT
    ejb_ee_bb_localaccess_mdbtaccesstest_MDB_TOPIC
    ejb_ee_deploy_mdb_ejblink_casesensT_TestBean
    ejb_ee_deploy_mdb_ejblink_scopeT_TestBean
    ejb_ee_deploy_mdb_ejblink_singleT_TestBean
    ejb_ee_deploy_mdb_ejblink_singleT_TestBeanBMT
    ejb_ee_deploy_mdb_ejbref_casesensT_TestBean
    ejb_ee_deploy_mdb_ejbref_scopeT_Cyrano
    ejb_ee_deploy_mdb_ejbref_scopeT_Romeo
    ejb_ee_deploy_mdb_ejbref_scopeT_Tristan
    ejb_ee_deploy_mdb_ejbref_singleT_TestBean
    ejb_ee_deploy_mdb_ejbref_singleT_TestBeanBMT
    ejb_ee_deploy_mdb_enventry_casesensT_CaseBean
    ejb_ee_deploy_mdb_enventry_casesensT_CaseBeanBMT
    ejb_ee_deploy_mdb_enventry_scopeT_Bean1_MultiJar
    ejb_ee_deploy_mdb_enventry_scopeT_Bean1_SameJar
    ejb_ee_deploy_mdb_enventry_scopeT_Bean2_MultiJar
    ejb_ee_deploy_mdb_enventry_scopeT_Bean2_SameJar
    ejb_ee_deploy_mdb_enventry_singleT_AllBean
    ejb_ee_deploy_mdb_enventry_singleT_AllBeanBMT
    ejb_ee_deploy_mdb_enventry_singleT_BooleanBean
    ejb_ee_deploy_mdb_enventry_singleT_ByteBean
    ejb_ee_deploy_mdb_enventry_singleT_DoubleBean
    ejb_ee_deploy_mdb_enventry_singleT_FloatBean
    ejb_ee_deploy_mdb_enventry_singleT_IntegerBean
    ejb_ee_deploy_mdb_enventry_singleT_LongBean
    ejb_ee_deploy_mdb_enventry_singleT_ShortBean
    ejb_ee_deploy_mdb_enventry_singleT_StringBean
    ejb_ee_deploy_mdb_resref_singleT_TestBean
    jms_ee_mdb_mdb_exceptT_MDB_DURABLETXNS_CMT
    jms_ee_mdb_mdb_exceptT_MDB_DURABLE_BMT
    jms_ee_mdb_mdb_exceptT_MDB_DURABLE_CMT
    jms_ee_mdb_mdb_msgHdrT_MDB_TOPIC
    jms_ee_mdb_mdb_msgPropsT_MDB_TOPIC
    jms_ee_mdb_mdb_msgTypesT1_MDB_TOPIC
    jms_ee_mdb_mdb_msgTypesT2_MDB_TOPIC
    jms_ee_mdb_mdb_msgTypesT3_MDB_TOPIC
    jms_ee_mdb_mdb_rec_MDB_TOPIC
    jms_ee_mdb_mdb_sndToTopic_MDB_TOPIC
    jms_ee_mdb_mdb_sndToTopic_MDB_TOPIC_REPLY
    jms_ee_mdb_xa_MDB_DURABLE_BMT
    jms_ee_mdb_xa_MDB_DURABLE_CMT
    testT0
    testT1
    testT2
    Note

    Implementations of TSJMSAdminInterface are called inside the JavaTest VM. The com.sun.ts.lib.deliverable.cts.CTSPropertyManager class, which is available to these implementations, provides access to any property in the ts.jte file.

5.4.16 Jakarta Authentication Service Test Setup

Jakarta Authentication Service for Containers (Authentication) 1.1 tests are security tests. The Jakarta Authentication Servlet (jaspicservlet) profile is the only required profile for Jakarta EE 9 Platform TCK. There are other optional profile tests, such as SOAP, but you are not required to run these for certification.

The test suite includes the following Ant targets that configure the test environment for the Jakarta Authentication tests

  • config_vi target in <TS_HOME>/bin/build.xml

  • enable.jaspic, also in <TS_HOME>/bin/build.xml

Both targets call <TS_HOME>/bin/xml/impl/glassfish/javaee_vi.xml, which then makes calls into <TS_HOME>/bin/xml/impl/glassfish/s1as.xml. You may want to examine these targets to see what is done in greater detail.

Complete the following steps before you run the Jakarta Authentication tests:

  1. Configure the Jakarta Authentication-required properties in the ts.jte file:

    1. Set the provider.configuration.file property to the location of your implementation’s instance lib directory, where it can be loaded when your implementation runtime is started.
      This file typically coexists with the tssv.jar file and the provider-configuration.dtd file.

    2. Set the vendor.authconfig.factory property to specify your AuthConfigFactory class.
      This property setting will be used by the Jakarta Authentication tests to register the test suite’s provider in your AuthConfigFactory.

    3. Set the logical.hostname.servlet property to the logical host that will process Servlet requests.
      Servlet requests may be directed to a logical host using various physical or virtual host names or addresses. A message processing runtime may be composed of multiple logical hosts. This setting is required to properly identify the Servlet profile’s application context identifier hostname. If the logical host that will process Servlet requests does not exist, you can set this to the default hostname of your implementation’s Web server.

    4. Set the servlet.is.jsr115.compatible property based on whether or not you are running the Servlet profile in a Jakarta Authorization 1.5 compatible container.

  2. Ensure that the config.vi Ant task has been run before running the enable.jaspic Ant task.
    These Ant tasks perform the following Jakarta Authentication-required steps:

    • Set up users and passwords for your implementation.
      See Step 9b in Configuring Your Application Server as the VI for more information.

    • Install the client-side certificate in the trustStore in your implementation.
      See Step 17 in Configuring Your Application Server as the VI for more information.

    • Append the file <TS_HOME>/bin/server_policy.append to the Java policy file or files on your implementation.
      See Step 17 in Configuring Your Application Server as the VIConfiguring Your Application Server as the VI for more information.

    • Appends the file <TS_HOME>/bin/client_policy.append to the application client’s Java policy file, which is referenced in the TestExecuteAppClient section of the ts.jte file.
      See Step 18 in Configuring Your Application Server as the VIConfiguring Your Application Server as the VI for more information.

    • Copies the <TS_HOME>/lib/tssv.jar file to your implementation instance library directory.
      The tssv.jar file includes the class files necessary to load TSAuthConfigFactory and related classes.

    • Copies the TSSV configuration files (ProviderConfiguration.xml, configuration.dtd) to your implementation instance library directory.
      The provider-configuration.dtd file is a DTD file that resides in the same directory as the ProviderConfiguration.xml file and describes the ProviderConfiguration.xml file. This file should not be edited.

    • Copies <TS_HOME>/bin/ts.java.security to <JAVAEE_HOME>/domains/domain1/config/ts.java.security, where <JAVAEE_HOME> is the location of your Jakarta EE 9 CI installation.

    • Sets the following JVM options:

      • -Djava.security.properties=<JAVAEE_HOME>/domains/domain1/config/ts.java.security

      • -Dlog.file.location=${log.file.location}

      • -Dprovider.configuration.file=${provider.configuration.file}

  3. Deploy the Jakarta Authentication log file processor, <TS_HOME>/dist/com/sun/ts/tests/jaspic/util/jaspic_util_web.war, to the implementation under test.

    Note

    It may be necessary to restart your implementation after completing this step.

  4. Run the tests for the profiles with which you are trying to certify.

  5. After running the Jakarta Authentication tests, change back to the <TS_HOME>/bin directory and execute the following command:

    cd <TS_HOME>/bin
    ant disable.jaspic

    This Ant task undoes the changes that were made to your implementation by the enable.jaspic target. If these changes are not reversed, your implementation may be left in an uncertain state.

5.4.17 Jakarta Authorization Test Setup

To comply with Jakarta EE 9 requirements, Jakarta Authorization must be supported in both the Web and Jakarta Enterprise Beans environments. The tests for each environment are divided into two directories:

  • src/com/sun/ts/tests/jacc/web

  • src/com/sun/ts/tests/jacc/ejb

When deploying the archives that contain Jakarta Authorization tests, don’t deploy all the Jakarta Authorization test archives at the same time. While this may work, there have been times when it has caused problems. The recommended course of action is to deploy the test archive for the directory under test. Once done, remove that archive and move onto another directory.

The Jakarta Authorization-TCK provider acts as a delegating security provider sitting between the appserver and vendor provider. The Jakarta Platform, Enterprise Edition appserver comes with a default security provider that is defined by two system properties; for the purposes of this discussion, these are referred to as A=DefaultProviderFactory and B=DefaultPolicyModule.

TCK moves the values from A and B to two new variables: C=DefaultProviderFactory and D=DefaultPolicyModule, replacing the TCK provider classes to the variables A and B (A=TSProviderFactory and B=TSPolicyModule). This modification allows the server to call the TCK provider for all its functions, and the TCK provider in turn uses these new variables to invoke the real provider.

The property names A, B, C, and D are used for convenience here. The real property names are as follows:

  • A=jakarta.security.jacc.PolicyConfigurationFactory.provider

  • B=jakarta.security.jacc.policy.provider

  • C=vendor.jakarta.security.jacc.PolicyConfigurationFactory.provider

  • D=vendor.jakarta.security.jacc.policy.provider

To configure the Jakarta Authorization provider for the Jakarta Platform, Enterprise Edition CI, execute the Jakarta Authorization Ant target from:

<TS_HOME>/bin

This command does the following:

  • Switches the system properties.

  • Adds tsprovider.jar to Jakarta Platform, Enterprise Edition application server’s classpath.

  • Adds log.file.location system property to the Jakarta Platform, Enterprise Edition application server’s system properties. This is used for generating log files, which is used for verifying Jakarta Authorization 1.5 contracts.

Note

When running Jakarta Authorization tests against the Jakarta EE 9 CI, if you need to restart the CI, be sure to first remove all Jakarta Authorization log files (jacc_log.*) from the JAVAEE_HOME/domains/domain1/logs directory before running the Jakarta Authorization tests again.

5.4.18 Jakarta Batch Test Setup

The Jakarta Batch tests, which are located under the <TS_HOME>/src/com/ibm/jbatch/tck directory, don’t require extra setup for most implementations. However, there may be a few cases where some customization is needed.

If you are using an injection technology other than CDI, complete the following steps before running the Jakarta Batch tests:

  1. Remove the <TS_HOME>/src/com/ibm/jbatch/tck/testJobXml/beans.xml and <TS_HOME>/src/com/ibm/jbatch/tck/tests/ee/beans.xml files.

  2. Change to the <TS_HOME>/src/com/ibm/jbatch/tck directory.

  3. Execute the ant build command to rebuild the archives.

If you are using a different implementation of the porting interface <<TS_HOME>/src/com/ibm/jbatch/tck/testJobXml/META-INF/services/com.ibm.jbatch.tck.spi.JobExecutionWaiterFactory, complete the following steps before running the Jakarta Batch tests:

  1. Change the entry in <TS_HOME>/src/com/ibm/jbatch/tck/testJobXml/META-INF/services/com.ibm.jbatch.tck.spi.JobExecutionWaiterFactory to specify the new porting implementation class.

  2. Change to the <TS_HOME>/src/com/ibm/jbatch/tck directory.

  3. Execute the ant build command to rebuild the archives.

For information about the Jakarta Batch tests themselves, see the Technology Compatibility Kit Reference Guide for JSR-352: Batch Applications for the Java Platform. This document is included with the TCK ZIP archive, or you may review the latest working copy, here.

All the Batch TCK material can be found here:

https://github.com/eclipse-ee4j/batch-tck

5.4.19 WSDL: Webservice Test and Runtime Notes

In addition to the WSDL elements described later in this section, the Jakarta Platform, Enterprise Edition CI webservice runtime DTDs contain two new optional elements for publishing and lookup of final WSDLs for a deployed webservice endpoint. These new tags are <wsdl-publish-location> and <wsdl-override>, and are used by the CTS to automate all TCK webservices tests, regardless of the host or port used to run the tests.

These WSDL tags are also used when performing file URL publishing, as required by Jakarta Implementing Web Services 1.4. Jakarta Implementing Web Services 1.4 states that http URL and file URL publishing must be supported on a Jakarta Platform, Enterprise Edition platform. In addition, the <wsdl-override> is used as a mechanism for satisfying the partial WSDL requirement in the Jakarta Implementing Web Services 1.4 specification. This mechanism enables the specification of the location of the final full published WSDL of a deployed webservice endpoint within the client EAR when only a partial WSDL is packaged, which enables client access to the full WSDL and correct SOAP address to communicate with the webservice.

The <wsdl-publish-location> tag tells the Jakarta Platform, Enterprise Edition CI where to publish the final WSDL for the deployed webservice endpoint. As stated above, the final WSDL can be published to a file URL or http URL, although the tag is really only necessary for file URL publishing, and is ignored if http URL publishing is specified (http is the default publishing used by the Jakarta Platform, Enterprise Edition CI). This tag is included in all TCK tests for consistency and to aid as a mechanism in automation.

By default, the Jakarta Platform, Enterprise Edition CI publishes the final WSDL during deployment to a http URL following a standard URL naming scheme. See below for details about the Jakarta Platform, Enterprise Edition CI runtime. This default can be overriden to explicitly do file URL publishing.

The <wsdl-override> tag tells the client application EAR where to lookup the final published WSDL for the deployed webservice endpoint. This will be either a file URL or an http URL to match what is specified in the <wsdl-publish-location> tag.

5.4.19.1 WSDL ts.jte Properties

For file URL publishing, the TCK defines two properties in the ts.jte file, named wsdlRepository1 and wsdlRepository2, which specify the file system directory location to use for publishing final WSDLs that use file URL publishing.

The wsdlRepository1 is used for the Vendor Jakarta Platform, Enterprise Edition Implementation. The wsdlRepository2 is used for the CI Jakarta Platform, Enterprise Edition Implementation, and is only used for CTS webservices interoperability testing. These directories get created by the TCK harness at runtime. The default settings in the ts.jte file will create these directories under:

wsdlRepository1=<TS_HOME>/tmp/wsdlRepository1
wsdlRepository2=<TS_HOME>/tmp/wsdlRepository2

For file URL publishing, the WSDL tag settings could be as follows:

$TS_HOME/src/com/sun/ts/tests/webservices/wsdlImport/file/Simple1
Webservice Endpoint
<wsdl-publish-location>
file:wsdlRepository1/Simple1File
</wsdl-publish-location>

Webservice Client Application
<wsdl-override>
file:wsdlRepository1/Simple1File/Simple1FileSvc.wsdl
</wsdl-override>

In this case, the TCK harness substitutes wsdlRepository1 with the setting in the <TS_HOME>/bin/ts.jte file.

For http URL publishing, the tag settings might be:

$TS_HOME/src/com/sun/ts/tests/webservices/wsdlImport/http/Simple1
Webservice Endpoint
<wsdl-publish-location>
http://webServerHost.1:webServerPort.1/Simple1Http/ws4ee?WSDL
</wsdl-publish-location>

Webservice Client Application
<wsdl-override>
http://webServerHost.1:webServerPort.1/Simple1Http/ws4ee?WSDL
</wsdl-override>

In this case, the TCK harness substitutes the webServerHost.1:webServerPort.1 with the settings in the <TS_HOME>/bin/ts.jte file.

Note

In the case of interop webservices tests, the TCK harness substitutes the webServerHost.2:webServerPort.2 with the settings in the ts.jte file. This host and port defines the CI Jakarta Platform, Enterprise Edition implementation used as the interop test machine. See tests/interop/webservices for these tests.

5.4.19.2 Webservice Endpoint WSDL Elements

The following are the webservice endpoint WSDL elements:

5.4.19.2.1 Setting Endpoint Address

element : endpoint-address-uri

The endpoint address URI is used to compose the endpoint address URL through which the endpoint can be accessed. It is required for Jakarta Enterprise Beans endpoints and optional for servlet endpoints.

The endpoint-address-uri can have an optional leading forward slash (/). It must be a fixed pattern (no asterisk (*) wildcards).

  • Jakarta Enterprise Beans Example:
    For Jakarta Enterprise Beans endpoints, the URI is relative to root of the web server; for example, if the web server is listening at http://localhost:8000, an endpoint address URI of google/GoogleSearch would result in an endpoint address of:

http://localhost:8000/google/GoogleSearch

Note that the first portion of the URI (google) should not conflict with the context root of any deployed web application.

<enterprise-beans>
    <module-name>ejb.jar</module-name>
    <ejb>
      <ejb-name>GoogleEjb</ejb-name>
      <webservice-endpoint>
        <port-component-name>GoogleSearchPort</port-component-name>
        <endpoint-address-uri>google/GoogleSearch</endpoint-address-uri>
      </webservice-endpoint>
    </ejb>
</enterprise-beans>
  • Servlet Example:
    For servlet endpoints, the endpoint-address-uri is only needed if the servlet does not have a servlet-mapping url-pattern in its web.xml. Its value is relative to the context root of the servlet’s web application.

<web>
    <module-name>web.war</module-name>
    <context-root>GoogleServletContext</context-root>
    <servlet>
        <servlet-name>MyGoogleServlet</servlet-name>
        <webservice-endpoint>
           <port-component-name>GoogleSearchPort</port-component-name>
           <endpoint-address-uri>/GoogleSearch</endpoint-address-uri>
         </webservice-endpoint>
    </servlet>
</web>

In this case, the target endpoint address would be:

http://localhost:8000/GoogleServletContext/GoogleSearch

5.4.19.2.2 Jakarta Enterprise Beans Endpoint Security

element : login-config

This only applies to Jakarta Enterprise Beans endpoints and is optional. It is used to specify how authentication is performed for Jakarta Enterprise Beans endpoint invocations. It consists of a single subelement named auth-method. auth-method is set to BASIC or CLIENT_CERT. The equivalent security for servlet endpoints is set through the standard web-application security elements. For example:

<ejb>
      <ejb-name>GoogleEjb</ejb-name>
      <webservice-endpoint>
        <port-component-name>GoogleSearchPort</port-component-name>
        <endpoint-address-uri>google/GoogleSearch</endpoint-address-uri>

        <login-config>
           <auth-method>BASIC</auth-method>
        </login-config>
      </webservice-endpoint>
</ejb>

5.4.19.2.3 Transport Guarantee

element : transport-guarantee

This is an optional setting on webservice-endpoint. The allowable values are NONE, INTEGRAL, and CONFIDENTIAL. If not specified, the behavior is equivalent to NONE. The meaning of each option is the same as is defined in the Security chapter of the Jakarta Servlet 5.0 Specification. This setting will determine the scheme and port used to generate the final endpoint address for a web service endpoint. For NONE, the scheme will be HTTP and port will be the default HTTP port. For INTEGRAL/CONFIDENTIAL, the scheme will be HTTPS and the port will be the default HTTPS port.

5.4.19.2.4 Publishing Final WSDL During Deployment

  • URL publishing: no extra information required.
    The final WSDL document for each webservice endpoint is always published to a URL having the following syntax:

    • Jakarta Enterprise Beans endpoints:

      <scheme>://<hostname>:<port>/<endpoint_address_uri>?WSDL
    • Servlet endpoints:

      <scheme>://<hostname>:<port>/<context-root><url-pattern>?WSDL

      or

      <scheme>://<hostname>:<port>/<context-root><endpoint_address_uri>?WSDL

      Note that the final WSDL document returned from this URL will contain port entries for all ports within the same service.

  • File publishing:

    element : wsdl-publish-location

    To have a copy of the final WSDL written to a file, set this element to a file URL; for example:

    <enterprise-beans>
        <module-name>ejb.jar</module-name>
        <webservice-description>
            <webservice-description-name>GoogleSearchService
            </webservice-description-name>
            <wsdl-publish-location>file:/home/user1/GoogleSearch_final.wsdl
            </wsdl-publish-location>
        </webservice-description>
    </enterprise-beans>

5.4.19.3 Webservice Client WSDL Elements

In the TCK for file publishing, the directory in which to publish the file WSDL is specified in the <wsdl-publish-location> tag for the webservice, and the full path of the WSDL file is specified in the <wsdl-override> tag in the client; for example:

<wsdl-publish-location>file:/files/wsdls/FileNested1</wsdl-publish-location>
<wsdl-override>file:/files/wsdls/FileNested1/nestedimportwsdl.wsdl</wsdl-override>

The Jakarta Platform, Enterprise Edition implementation defines the behavior this way because, for wsdl-publish-location, the App Server is potentially publishing many documents, not just one. This is because the main WSDL could have dependencies on relative imports. There is no requirement that the initial WSDL be located at the top of the hierarchy, even though that is commonly the case.

For example, in an ejb-jar with a Main.wsdl that imports a relative WSDL at ../../Relative.wsdl, the packaging would look like:

META-INF/wsdl/a/b/Main.wsdl
META-INF/wsdl/Relative.wsdl

The wsdl-publish-location tells the TCK where to locate the topmost part of the WSDL content hierarchy. So, given a wsdl-publish-location of /home/foo/wsdlpublishdir, this location would look like:

/home/foo/wsdlpublishdir/Relative.wsdl
/home/foo/wsdlpublishdir/a/b/Main.wsdl

The wsdl-override property still always points to a specific WSDL document, which in this case would be /home/foo/wsdlpublishdir/a/b/Main.wsdl.

5.4.19.3.1 Resolving Container-Managed Ports

element : wsdl-port

Used to resolve the port to which a service-ref Service Endpoint Interface is mapped. Only required for each port-component-ref in the service-ref that does not have a port-component-link. For example:

<service-ref>
      <service-ref-name>service/GoogleSearchProxy</service-ref-name>
      <port-info>
        <service-endpoint-interface>googleclient.GoogleSearchPort
        </service-endpoint-interface>
        <wsdl-port>
           <namespaceURI>urn:GoogleSearch</namespaceURI>
           <localpart>GoogleSearchPort</localpart>
        </wsdl-port>
   </port-info>
</service-ref>

5.4.19.3.2 Overriding WSDL
element : wsdl-override

The wsdl-override element forces the deployment process to use a different WSDL than the one associated with a service-ref in the standard deployment module. This element is optional if the service-ref WSDL is full WSDL, and is required if partial WSDL. In all cases, it must point to a valid URL of a full WSDL document. Some examples are shown below.

  • To use the final WSDL generated upon deployment of the EJB endpoint shown above:

    <service-ref>
          <service-ref-name>service/GoogleSearch</service-ref-name>
          <wsdl-override>http://localhost:8000/google/GoogleSearch?WSDL
          </wsdl-override>
    </service-ref>
  • An alternate way to do the same thing by means of a file URL that matches a webservice’s wsdl-publish-location could be:

    <service-ref>
          <service-ref-name>service/GoogleSearch</service-ref-name>
          <wsdl-override>file:/home/user1/GoogleSearch_final.wsdl
          </wsdl-override>
    </service-ref>

5.4.20 Jakarta Security API Test Setup

Complete the following steps before you run the Jakarta Security API tests:

  1. Set the following properties in the ts.jte file:

    Note

    An LDAP server is required in Jakarta Security API testing. You could either use an already existing external LDAP server or use TCK script to install an internal LDAP server.

    Choose one of these two options to make an LDAP server ready for testing:

  2. Use internal LDAP server - Unbounded (Recommended, and would be installed by default.)

    Note
    1. Ensure the ldap.server property is unbounded.

    2. Ensure the path of ldap.ldif.file is correct.

    3. Ensure the port 11389 is not occupied. Kill any related process using port 11389.

    Note

    Parts of ts.jte:

    • ldap.server=unboundid

    • ldap.install.server=true

    • ldap.ldif.file=$\{ts.home}/bin/ldap.ldif

  3. Use external LDAP server.

    Note
    1. Ensure the port of LDAP server is 11389.

    2. Update ldap.install.server property as false since TCK script need not install LDAP server.

    3. Import ldap.ldif file into Ldap server. You can get ldap.ldif from <TS_HOME>/install/jakartaee/bin/ldap.ldif.

    Note

    Part of ts.jte - ldap.install.server=false

  4. Configure the VI environment using these commands to run the Jakarta Security API test (including Derby, internal Ldap server which are required by Jakarta Security 1.0):

    1. cd <TS_HOME>/bin

    2. ant config.vi

    3. Start your database.

    4. ant init.ldap

      Note

      If you use the external LDAP server, do not run the command ant init.ldap.

5.4.21 Signature Test Setup

The signature test setup includes the following:

5.4.21.1 sigTestClasspath Property

Set the sigTestClasspath property in the <TS_HOME>/bin/ts.jte file to include a CLASSPATH containing the following:

sigTestClasspath=jar_to_test:jars_used_by_yours

where:

  • ``jar_to_test``: The JAR file you are validating when running the signature tests; when running against the Jakarta Platform, Enterprise Edition CI, Eclipse GlassFish 6.0, set to javaee.jar

  • ``jars_used_by_yours``: The JAR file or files that are used or referenced by your JAR file; must include any classes that might be extended or implemented by the classes in your jar_to_test; include rt.jar when running against the Jakarta Platform, Enterprise Edition CI

5.4.21.2 Additional Signature Test Information

The Jakarta EE 9 Platform TCK signature tests perform verifications in two different modes: static and reflection. The test results list which SPEC API signature tests pass or fail, and the mode (static or reflection) for that test.

Any signature test failure means one of two things, either you have not yet corrected the sigTestClasspath or the respective SPEC API jar in your Jakarta EE implementation needs a modification to exactly match the Jakarta EE 9 Platform SPEC API. Your implementation SPEC API jars cannot contain additional public methods/fields, nor can it be missing any expected public methods/fields.

As a troubleshooting aid when failures occur, consider the following:

  • All static mode tests fail:
    Verify that the sigTestClasspath is using correct SPEC API file names. When running on Windows, be sure to use semicolons (;) for CLASSPATH separators.

  • For all other signature test failures:
    Check the report output from the test to determine which tests failed and why.

For example, some failures from an actual JavaEESigTest_signatureTest_from_servlet.jtr failure: ` SVR: Status Report jakarta.servlet.jsp.jstl.core

SVR: SignatureTest report Base version: 2.0_se8 Tested version: 2.0_se8 Check mode: src [throws normalized] Constant checking: on

Missing Fields :

jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.FMT_FALLBACK_LOCALE = "jakarta.servlet.jsp.jstl.fmt.fallbackLocale" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.FMT_LOCALE = "jakarta.servlet.jsp.jstl.fmt.locale" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.FMT_LOCALIZATION_CONTEXT = "jakarta.servlet.jsp.jstl.fmt.localizationContext" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.FMT_TIME_ZONE = "jakarta.servlet.jsp.jstl.fmt.timeZone" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.SQL_DATA_SOURCE = "jakarta.servlet.jsp.jstl.sql.dataSource" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.SQL_MAX_ROWS = "jakarta.servlet.jsp.jstl.sql.maxRows"

Added Fields :

jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.FMT_FALLBACK_LOCALE = "javax.servlet.jsp.jstl.fmt.fallbackLocale" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.FMT_LOCALE = "javax.servlet.jsp.jstl.fmt.locale" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.FMT_LOCALIZATION_CONTEXT = "javax.servlet.jsp.jstl.fmt.localizationContext" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.FMT_TIME_ZONE = "javax.servlet.jsp.jstl.fmt.timeZone" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.SQL_DATA_SOURCE = "javax.servlet.jsp.jstl.sql.dataSource" jakarta.servlet.jsp.jstl.core.Config: field public final static java.lang.String jakarta.servlet.jsp.jstl.core.Config.SQL_MAX_ROWS = "javax.servlet.jsp.jstl.sql.maxRows"

SVR: Package jakarta.servlet.jsp.jstl.core - FAILED (STATIC MODE) `

The failure above is a little strange, isn’t it? Why are there missing fields? Why are there added fields? The failure means that the jakarta.servlet.jsp.jstl.core.Config class needs to be updated to assign the correct values to the indicated constant fields. Basically, instead of setting Config.FMT_FALLBACK_LOCALE = "javax.servlet.jsp.jstl.fmt.fallbackLocale", you should set Config.FMT_FALLBACK_LOCALE = "jakarta.servlet.jsp.jstl.fmt.fallbackLocale" The same correction is needed for the other identified fields as well.

Another example only with methods is:

` SVR: Status Report jakarta.el

SVR: SignatureTest report Base version: 4.0_se8 Tested version: 4.0_se8 Check mode: src [throws normalized] Constant checking: on

Missing Methods :

jakarta.el.ELContext: method public java.lang.Object jakarta.el.ELContext.getContext(java.lang.Class<?>) jakarta.el.ELContext: method public void jakarta.el.ELContext.putContext(java.lang.Class<?>,java.lang.Object) jakarta.el.StandardELContext: method public java.lang.Object jakarta.el.StandardELContext.getContext(java.lang.Class<?>) jakarta.el.StandardELContext: method public void jakarta.el.StandardELContext.putContext(java.lang.Class<?>,java.lang.Object)

Added Methods :

jakarta.el.ELContext: method public java.lang.Object jakarta.el.ELContext.getContext(java.lang.Class) jakarta.el.ELContext: method public void jakarta.el.ELContext.putContext(java.lang.Class,java.lang.Object) jakarta.el.StandardELContext: method public java.lang.Object jakarta.el.StandardELContext.getContext(java.lang.Class) jakarta.el.StandardELContext: method public void jakarta.el.StandardELContext.putContext(java.lang.Class,java.lang.Object) `

The failure above is a little strange, isn’t it? Why are there missing methods? Why are there added methods? The failure means that the java.lang.Object jakarta.el.ELContext.getContext(java.lang.Class) method needs a signature change from getContext(Class key) to getContext(Class<?> key). The same correction is needed for the other identified methods as well.

Note

Refer to Chapter 8, "Debugging Test Problems" for additional debugging information.

5.4.22 Backend Database Setup

The following sections address special backend database setup considerations:

5.4.22.1 Setup Considerations for MySQL

The Jakarta Persistence API (formerly JPA) tests require delimited identifiers for the native query tests. If you are using delimited identifiers on MySQL, modify the sql-mode setting in the my.cnf file to set the ANSI_QUOTES option. After setting this option, reboot the MySQL server. Set the option as shown in this example:

sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ANSI_QUOTES"

5.4.22.2 Setup Considerations for MS SQL Server

If your database already exists and if you use a case-sensitive collation on MS SQL Server, execute the following command to modify the database and avert errors caused by case-sensitive collation:

ALTER DATABASE ctsdb
COLLATE Latin1_General_CS_AS ;
Note

You need to generate your own deployment plan for each module type, using the deployment tool that comes with your Jakarta Platform, Enterprise Edition server.

5.5 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 TCK test environment. After familiarizing yourself with these basic configuration settings, you will probably want to continue with the instructions in Modifying Environment Settings for Specific Technology Tests.

5.5.1 Basic Configuration 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:

  1. 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.

  2. 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.

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.

Once the JavaTest harness GUI is displayed, whenever you choose Run Tests and then Start 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.

5.5.2 The Configuration Interview

To configure the JavaTest harness to run the Jakarta EE 9 Platform TCK tests, complete the following steps. Note that you only need to complete these steps the first time you start the JavaTest harness. After you complete these steps, you can either run all or a subset of the tests, as described in Chapter 7, "Executing Tests".

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

    cd <TS_HOME>/bin
    ant gui

    The Welcome screen displays.

  2. Click File, then click Create Work Directory to create a new work directory.
    If you already have a working directory you want to use, click File, then click Open Work Directory instead.
    At this point, the JavaTest harness is preconfigured to run the basic TCK tests.

  3. If you want to run the test suite at this time using your current configuration settings, select Run Tests from the main menu, then select Start.
    The default tests are executed with the default configuration settings.
    If you do not want to run the test suite at this time, continue with the steps below to modify your test configuration.

  4. Select Configure from the main menu, then select Edit Configuration.
    The Configuration Welcome screen displays.

  5. Click Next (right arrow).
    You are prompted to specify one or more configuration files that contain information about your test environment. By default, this file is <TS_HOME>/bin/ts.jte.

  6. Accept the default configuration file and click Next.
    You are prompted to specify a test environment.

  7. Select either ts_unix or ts_win32, and then click Next.
    Choose ts_unix if you are running the tests in a Unix or Linux environment; choose ts_win32 if you are running the tests under Windows.
    After making your selection and clicking Next, you are prompted to specify whether you want to run all or a subset of the test suite.

  8. Specify whether you want to run all or a subset of the tests, and then click Next.
    Select Yes to run a subset of the tests; select No to run all tests.
    If you select Yes, proceed to the next step. If you select No, skip to Step 10.

  9. Select the tests you want to run from the displayed test tree, and then click Next.
    You can select entire branches of the test tree, or use Ctrl+Click or Shift+Click to select multiple tests or ranges of tests, respectively.

  10. Specify whether you want to use an exclude list, and then click Next.
    Select Yes to use an exclude list; select No to not use an exclude list.
    If you select Yes, proceed to the next step. If you select No, skip to Step 13.

  11. Specify the exclude list you want to use, and then click Next.
    Select initial to use the default list; select custom to use a custom list.
    If you select custom, proceed to the next step. If you select initial, skip to Step 13.

  12. Specify the custom exclude list file to use, and then click Next.

  13. Click Done to accept and save your configuration settings.
    You are prompted to specify the location in which you want to save your configuration settings.

  14. Specify the file in which you want to save your configuration settings, and then click Save File.
    You are returned to the JavaTest main window.

  15. If you want to run the test suite at this time using your current configuration settings, select Run Tests from the main menu, then select Start.
    The default tests are executed with the settings you specified.


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