cd <TS_HOME>/bin
ant
Setup and Configuration |
Previous | Next | Contents |
Note
|
The Jakarta EE Specification process provides for any number of compatible implementations. As additional implementations become available, refer to project or product documentation from those vendors for specific TCK setup and operational guidance. |
This chapter describes how to set up the Connectors TCK and JavaTest harness software. Before proceeding with the instructions in this chapter, be sure to install all required software, as described in Chapter 3, "Installation."
After completing the instructions in this chapter, proceed to Chapter 5, "Executing Tests," for instructions on running the Connectors TCK.
After configuring your environment as described in this section, continue with the instructions in Section 4.6, "Using the JavaTest Harness Software."
Note
|
In these instructions, variables in angle brackets need to be expanded
for each platform. For example, On Windows, you must escape any backslashes with an extra backslash in path separators used in any of the following properties, or use forward slashes as a path separator instead. |
Set the following environment variables in your shell environment:
JAVA_HOME
to the directory in which Java SE 8 is installed
TS_HOME
to the directory in which the Connectors TCK
1.7 software is installed
JAVAEE_HOME
to the directory in which the Connectors
1.7 CI has been installed
PATH
to include the following directories: JAVA_HOME/bin
,
JAVAEE_HOME/bin
, and <TS_HOME>/tools/ant/bin
Edit your <TS_HOME>/bin/ts.jte
file and set the following
environment variables:
Set the webServerHost
property to the name of the host on which
Jakarta EE 8 CI is running.
The default setting is localhost
.
Set the webServerPort
property to the port number of the host on
which Jakarta EE 8 CI is running.
The default setting is 8080
.
connector.home
to the location where your Connectors runtime
implementation is installed.
orb.host
to the hostname of the system on which your
Connectors runtime was installed.
orb.port
to the port number of the system on which your
Connectors runtime was installed.
connector.classes
to the Connectors classes or JAR
files that contain the Connectors classes.
sigTestClasspath
to the to the classes or JAR file (or files) for
the runtime implementation of the Connectors API and any additional
required signature or Connectors API classes.
impl.vi
to the directory where vendor-specific targets can best be
stored and isolated. The default directory if you are using Eclipse GlassFish 5.1, glassfish
, is where
details about the installation and configuration of the Eclipse GlassFish 5.1
enterprise server can be found.
report.dir
to the default directory in which JavaTest creates a
test report for the most recent test run.
This property is a required property for the TCK Ant targets; it must be
set. To disable reporting, set the report.dir
property to none
.
work.dir
to the default directory in which JavaTest writes
temporary files that are created during test execution.
This property is required for the TCK Ant targets.
Provide your own implementations of the porting package interfaces
provided with the Connectors TCK.
TSURLInterface.java
obtains URL strings for web resources in an
implementation-specific manner. API documentation for the
TSURLInterface.java
porting package interface is available in the
documentation bundle in the docs/api
directory.
Execute the config.vi
Ant task.
This target performs the following tasks:
Stops the application server running the Connectors 1.7 CI
Copies the TCK-dependent files ${tslib.name}.jar
and tsharness.jar
into the application server’s external library folder
Starts the application server
Sets the appropriate JVM options in the runtime
Creates connection pools and connection resources
Deploys the required RAs
Creates users in the runtime, then maps RA users to these runtime
users
Ensure that the users and passwords specified in the ts.jte
file are
created in the Connectors server. These users and passwords
include the ts.jte
properties of rauser1
, rapassword1
, user
,
password
, authuser
, authpassword
, user_vi
, password_vi
, and
so on.
After configuring your environment as described in this section, continue with the instructions in Section 4.4, "Using the JavaTest Harness Software."
Note
|
In these instructions, variables in angle brackets need to be expanded
for each platform. For example, On Windows, you must escape any backslashes with an extra backslash in path separators used in any of the following properties, or use forward slashes as a path separator instead. |
Adapt the instructions above for your environment.
The JCA 1.7 TCK RAR files are deployed simultaneously.
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 standalone RAR files can access. This
extension library is needed to address classloading issues.
The Resource Adapter (RAR) files that are used with the JCA 1.7 TCK
differ from those that were used in earlier JCA TCK releases. The TCK no
longer includes the same common classes into every RAR file. Duplicate
common classes, such as whitebox.jar
, have been removed from each RAR
file and are now handled as an Installed Library.
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 Java EE 7 platform specification and section
20.2.0.1 in the JCA 1.7 specification, which explicitly state that the
resource adapter server may employ the library mechanisms in Java EE 7.
Support application-based standalone connector accessibility
See section 20.2.0.4 of the JCA 1.7 specification, which uses the
classloading requirements listed in section 20.3 in the specification.
The JCA TCK 1.7 has scenarios in which multiple standalone RAR files
that use the same shared library (for example, whitebox.jar
) are
referenced from a TCK 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 previous versions of the TCK,
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.
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 Java EE 7 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 the Eclipse GlassFish 5.1 CI, domain-dir/lib/applibs
is used as the Installed
Library directory and is the location to which the whitebox.jar
file
gets copied. Refer to specific instructions for other CIs.
The JCA 1.7 TCK 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 Java EE 7 platform specification for information about the reference 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.
The JCA TCK tests should only be deployed after you properly configure your connector runtime. This configuration includes creating users and JVM options in the runtime, mapping RA users to existing runtime users, deploying RAs, and creating connection pools and connection resources.
Deployment of the connector resource adapters involves the deployment of 17 RAR files:
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
whitebox-ibanno_no_md.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 |
Deploying RAR files require the installation of a whitebox.jar
file to
a directory into which the server can load. The whitebox.jar
file is a
common library, which is referenced and used by all the RAR files. To
ensure proper class loading, the whitebox.jar
file must be copied into
the application server’s domains/domain1/lib/applibs
directory, a
location where it can be loaded by the server and can be accessed by all
the RAR files.
To deploy the Connectors TCK tests to the Jakarta EE 8 platform, perform the following steps.
The config.vi
Ant task performs several configuration procedures on
your connector server. This target deploys some of the required Resource
Adapters (RAR files) and creates some connection resources and
connection pools. The test suite also provides a convenience Ant target,
which deploys only the RAR files and creates connection pools and
connection resources. This Ant target is in the
<TS_HOME>/bin/xml/impl/glassfish/connector.xml
file. See the Ant
target setup.all.rars.and.pools
for more information.
Make sure that the server to which you will deploy the JCA TCK tests is running.
Change to the <TS_HOME>/bin
directory and execute the Ant task to
configure the CI.
cd <TS_HOME>/bin
ant
Execute the ant deploy.all
Ant task to deploy the requisite RAR
files.
ant deploy.all
Follow the instructions in Section 5.1, "Using the GUI for TCK Test Execution," or Section 5.2, "Using the Command-Line for TCK Test Execution," to run the tests you just deployed.
Vendors need to configure their application or connector servers to run
the TCK tests. This configuration needs to support the same features
that are currently performed against all CIs through the execution of the
config.vi
and setup.all.rars.and.pools
Ant targets.
This section describes how to configure the Vendor Implementation (VI) before running the JCA TCK tests.
Performing the tasks of these targets should minimally include the following:
See the Ant target create.security.eis.mappings
in the
<TS_HOME>/bin/xml/impl/glassfish/connector.xml
to see how this is done
with the Eclipse GlassFish 5.1 CI. This task maps Resource Adapter user information to
existing user information in the connector runtime.
For the Eclipse GlassFish 5.1 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
Create the required JVM options to allow the passing and/or setting of
user information from the ts.jte
file to the server. These properties
are set in the connector runtime for use by the RAR files, which are
deployed to the connector runtime. The RAR files need to know some of
the property settings used in the ts.jte
file; this is the means used
to specify some of the user properties.
To see some of required JVM options for the Eclipse GlassFish 5.1 CI, examine the
ri.jvm.options
property in the ts.jte
file. The following subset of
JVM option specified in the ri.jvm.options
property must be set in the
connector runtime:
-Dj2eelogin.name=j2ee
-Dj2eelogin.password=j2ee
-Deislogin.name=cts1
-Deislogin.password=cts1
If your connector server does not have web support, you will need to
create your own vehicle. A vehicle is a wrapper that supports running
tests in different server-side containers, such as servlet, JSP, and so
on. The JCA TCK provides a default vehicle, connectorservlet
, which
supports running the TCK tests in a connector runtime that has a Servlet
container. To support running tests in an environment other than a
Servlet container, you need to implement your own vehicle, effectively
replacing the default vehicle, connectorservlet
.
This TCK was designed so you could use connectorservlet
as a template
for creating your own vehicle. The connectorservlet
vehicle is used to
contain and execute your client-side tests in the connector runtime.
The connectorservlet
vehicle is located in the
<TS_HOME>/src/com/sun/ts/tests/common/vehicle/connectorservlet
directory.
To run the tests in a vehicle other than connectorservlet
, you need to
create a custom vehicle named customvehicle
. See Section
4.2.2, "To Create a Custom Vehicle," for more information on this
topic.
This section describes how deploy the RAR files to the VI before running the JCA TCK tests.
The deployment requirements for VI are similar to the requirements for
the CI in that the required Resource Adapter (RAR) files must be
deployed before any TCK tests can be run. Before you attempt to deploy
the RAR files, ensure your connector server has been properly
configured. For additional information about deploying the RAR files and
creating the corresponding connection pools and connection resources,
see the setup.all.rars.and.pools
Ant target in the
<TS_HOME>/bin/xml/impl/glassfish/connector.xml file
.
Configuration handlers are used to configure and unconfigure a Connectors 1.7 implementation during the certification process. These are similar to deployment handlers but used for configuration. A configuration handler is an Ant build file that contains at least the required targets listed below:
config.vi
- to configure the vendor implementation
clean.vi
- to unconfigure the vendor implementation
These targets are called from the <TS_HOME>/bin/build.xml
file and
call down into the implementation-specific configuration handlers.
To provide your own configuration handler, create a config.vi.xml file
with the necessary configuration steps for your implementation and place
the file under the <TS_HOME>/bin/xml/impl/<your_impl>
directory.
For more information, you may wish to view <TS_HOME>/bin/xml/impl/glassfish/config.vi.xml
,
the configuration file for Eclipse EE4J Jakarta EE 8 Compatible Implementation, Eclipse GlassFish.
Deployment handlers are used to deploy and undeploy the WAR files that contain the tests to be run during the certification process. A deployment handler is an Ant build file that contains at least the required targets listed in the table below.
The Connectors TCK provides these deployment handlers:
<TS_HOME>/bin/xml/impl/none/deploy.xml
<TS_HOME>/bin/xml/impl/glassfish/deploy.xml
<TS_HOME>/bin/xml/impl/tomcat/deploy.xml
The deploy.xml
files in each of these directories are used to control
deployment to a specific container (no deployment, deployment to
the Eclipse GlassFish Web container, deployment to the Tomcat Web container)
denoted by the name of the directory in which each deploy.xml
file
resides. The primary build.xml
file in the <TS_HOME>/bin
directory
has a target to invoke any of the required targets (-deploy
, -undeploy
,
-deploy.all
, -undeploy.all
).
To deploy tests to another Connectors implementation, you must create a custom handler.
Create a new directory in the <TS_HOME>/bin/xml/impl
directory tree.
For example, create the <TS_HOME>/bin/xml/impl/my_deployment_handler
directory.
Replace my_deployment_handler with the value of the impl.vi
property that you set in Step 5 of the configuration procedure
described in Section 4.2, "Configuring Your Environment to Repackage
and Run the TCK Against the Vendor Implementation".
Copy the deploy.xml file from the <TS_HOME>/bin/xml/impl/none
directory to the directory that you created.
Modify the required targets in the deploy.xml
file. This is what
the deploy.xml
file for the "none" deployment handler looks like.
<project name="No-op Deployment" default="deploy">
<!-- No-op deployment target -->
<target name="-deploy">
<echo message="No deploy target implemented for this deliverable"/>
</target>
<target name="-undeploy">
<echo message="No undeploy target implemented for this deliverable"/>
</target>
<target name="-deploy.all">
<echo message="No deploy target implemented for this deliverable"/>
</target>
<target name="-undeploy.all">
<echo message="No undeploy target implemented for this deliverable"/>
</target>
</project>
Although this example just echoes messages, it does include the four
required Ant targets (-deploy
, -undeploy
, -deploy.all
, -undeploy.all
)
that your custom deploy.xml
file must contain. With this as your
starting point, look at the required targets in the deploy.xml
files
in the Tomcat and Eclipse Glassfish directories for guidance as you create
the same targets for the Web container in which you will run your
implementation of Connectors.
The following Ant targets can be called from anywhere under the
<TS_HOME>/src
directory:
deploy
undeploy
deploy.all
undeploy.all
The deploy.all
and undeploy.all
targets can also be called from the
<TS_HOME>/bin
directory.
Note
|
The targets in the |
There are two general ways to run the Connectors TCK test suite using the JavaTest harness software:
Through the JavaTest GUI; if using this method, please continue on to Section 4.7, "Using the JavaTest Harness Configuration GUI."
In JavaTest batch mode, from the command line in your shell environment; if using this method, please proceed directly to Chapter 5, "Executing Tests."
You can use the JavaTest harness GUI to modify general test settings and to quickly get started with the default Connectors TCK test environment. This section covers the following topics:
Note
|
It is only necessary to proceed with this section if you want to run the JavaTest harness in GUI mode. If you plan to run the JavaTest harness in command-line mode, skip the remainder of this chapter, and continue with Chapter 5, "Executing Tests." |
In order for the JavaTest harness to execute the test suite, it requires information about how your computing environment is configured. The JavaTest harness requires two types of configuration information:
Test environment: This is data used by the tests. For example, the path to the Java runtime, how to start the product being tested, network resources, and other information required by the tests in order to run. This information does not change frequently and usually stays constant from test run to test run.
Test parameters: This is information used by the JavaTest harness to run the tests. Test parameters are values used by the JavaTest harness that determine which tests in the test suite are run, how the tests should be run, and where the test reports are stored. This information often changes from test run to test run.
The first time you run the JavaTest harness software, you are asked to specify the test suite and work directory that you want to use. (These parameters can be changed later from within the JavaTest harness GUI.)
Once the JavaTest harness GUI is displayed, whenever you choose Start, then Run Tests to begin a test run, the JavaTest harness determines whether all of the required configuration information has been supplied:
If the test environment and parameters have been completely configured, the test run starts immediately.
If any required configuration information is missing, the configuration editor displays a series of questions asking you the necessary information. This is called the configuration interview. When you have entered the configuration data, you are asked if you wish to proceed with running the test.
Before you start the JavaTest harness software, you must have a valid test suite and Java SE 8 installed on your system.
The Connectors TCK includes an Ant script that is used to execute the
JavaTest harness from the <TS_HOME>
directory. Using this Ant script
to start the JavaTest harness is part of the procedure described in
Section 4.7.3, "To Configure the JavaTest Harness to Run the
TCK Tests."
When you execute the JavaTest harness software for the first time, the JavaTest harness displays a Welcome dialog box that guides you through the initial startup configuration.
If it is able to open a test suite, the JavaTest harness displays a Welcome to JavaTest dialog box that guides you through the process of either opening an existing work directory or creating a new work directory as described in the JavaTest online help.
If the JavaTest harness is unable to open a test suite, it displays a Welcome to JavaTest dialog box that guides you through the process of opening both a test suite and a work directory as described in the JavaTest documentation.
After you specify a work directory, you can use the Test Manager to configure and run tests as described in Section 4.7.3, "To Configure the JavaTest Harness to Run the TCK Tests."
The answers you give to some of the configuration interview questions are specific to your site. For example, the name of the host on which the JavaTest harness is running. Other configuration parameters can be set however you wish. For example, where you want test report files to be stored.
Note that you only need to complete all these steps the first time you start the JavaTest test harness. After you complete these steps, you can either run all of the tests by completing the steps in Section 5.1, "Starting JavaTest," or run a subset of the tests by completing the steps in Section 5.2, "Running a Subset of the Tests."
Change to the <TS_HOME>/bin
directory and start the JavaTest test
harness:
cd <TS_HOME>/bin
ant gui
From the File menu, click Open Quick Start Wizard.
The Welcome screen displays.
Select Start a new test run, and then click Next.
You are prompted to create a new configuration or use a configuration
template.
Select Create a new configuration, and then click Next.
You are prompted to select a test suite.
Accept the default suite (<TS_HOME>/src
), and then click Next.
You are prompted to specify a work directory to use to store your test
results.
Type a work directory name or use the Browse button to select a work
directory, and then click Next.
You are prompted to start the configuration editor or start a test run.
At this point, the Connectors TCK is configured to run the
default test suite.
Deselect the Start the configuration editor option, and then click Finish.
Click Run Tests, then click Start.
The JavaTest harness starts running the tests.
To reconfigure the JavaTest test harness, do one of the following:
Click Configuration, then click New Configuration.
Click Configuration, then click Change Configuration.
Click Report, and then click Create Report.
Specify the directory in which the JavaTest test harness will write
the report, and then click OK.
A report is created, and you are asked whether you want to view it.
Click Yes to view the report.
The JavaTest GUI enables you to configure numerous test options. These options are divided into two general dialog box groups:
Group 1: Available from the JavaTest Configure/Change Configuration submenus, the following options are displayed in a tabbed dialog box:
Tests to Run
Exclude List
Keywords
Prior Status
Test Environment
Concurrency
Timeout Factor
Group 2: Available from the JavaTest Configure/Change
Configuration/Other Values submenu, or by pressing Ctrl+E
, the following
options are displayed in a paged dialog box:
Environment Files
Test Environment
Specify Tests to Run
Specify an Exclude List
Note that there is some overlap between the functions in these two dialog boxes; for those functions use the dialog box that is most convenient for you. Please refer to the JavaTest Harness documentation or the online help for complete information about these various options.
Previous | Next | Contents |