JBoss.orgCommunity Documentation

Chapter 8. Build and testsuite framework

8.1. Introduction
8.1.1. Prerequisites and requirements
8.2. Architecture overview
8.2.1. Target Container Identification
8.2.2. Port Mapping
8.3. Command Line Options
8.3.1. Profile
8.3.2. Options
8.3.3. Examples
8.4. Container remote debugging

The JBossWS project build and testsuites have been completely revisited in version 5.0.0.Beta3. As a result, JBossWS uses the Arquillian framework to run its integration tests against WildFly containers.

There are three test modules in JBossWS' testsuite, cxf-tests , shared-tests and cxf-spring-tests . Each test module requires at least one WildFly container to run; multiple containers are used for modules whose tests can't run at the same time on the same container. By default, containers are managed (started / stopped) by Arquillian.The JBossWS build system fetches a copy of the required container from the Maven repository, unpacks it, patches it installing the current webservices stack on it and finally hands it over to Arquillian for the testsuite runs. The test framework also allows letting Arquillian manage an already available container instance on the local filesystem. Finally, it's also possible to execute single tests against a locally running container (non-Arquillian managed) and run the tests concurrently.

When the build fetches the a container from the Maven repository, a patched copy of it is put within the target/test-server sub-directory of each testsuite module. For instance, you could have:

Each container copy is also provided with specific standalone mode configuration files ( jbws-testsuite-SOME_IDENTIFIER.xml ) in the standalone/configuration server directory. The actual contents of such descriptors depends on the tests that are to be run against such container configurations (the most common difference when compared to the vanilla standalone.xml is the setup op additional security domains, system properties, web connectors etc.) Each configuration also includes logging setup to ensure logs are written to unique files ( jbws-testsuite-SOME_IDENFIFIER.log ) in standalone/log directory.

JBossWS supports the current WildFly release and several back versions for testing. See the supported target containers page for details. Maven profiles are used to identify the target container to be used for testing. The naming convention is wildflyXYZ , for example wildfly820 to mean WIldFly 8.2.0.Final.

To run tests against an existing local copy of a WildFly container, the user must specify the absolute path to the server implementation's home directory using the command line option, -Dserver.home=/foo/bar . The server is not expected to be running, as the build will create various standalone server configurations and start multiple instances on different port numbers. However, if a single test of few tests are executed only, the user can have those executed against live WildFly instances previously started on the same port numbers expected by the tests. Arquillian is configured to detect such scenario and use the available server.

As any other Maven-based project, JBossWS is built as follows:

JBossWS uses Maven profiles to declare the target container and other types of environment setup. Multiple profiles are provided as a comma separated list of profile names. Only a single target container profile is allowed at the same time though.




Designates the target container to use, where XYZ is WildFly's three digit version number


Enables Spring support; this causes Spring libraries to be installed on the target container and the cxf-spring-tests testsuite module to be also run


Declares the tests are to be run concurrently


Explicitly includes dist module in the build; by default this is automatically triggered (only) when a wildflyXYZ profile is set.


Explicitly includes the testsuite modules in the build; by default this is automatically triggered (only) when a wildflyXYZ profile is set.

Below is a list of the available build / test options:




Declares the absolute path to a given local server instance.


Force skipping the UDP tests. This option might be needed when running on a network that does not allow UDP broadcast.


Do not upgrade the WS stack on the target server container.


Skip integration tests preparation phase, which includes tuning of the server configurations, wsconsume/wsprovide invocations, etc.


Turns on Surefire debugging of integration tests only. Debugging address is 5005.


Starts the containers bound to the specified network interface address.


Instructs Arquillian to write the actual test deployments to disk in the specified module sub-directory.


Runs the testcases in the specified comma-separated list of JUnit classes


Turns on Surefire debugging in any module including tests.

While debugging the a testcase is simply a matter of providing the -Ddebug option, remote debugging the container code that runs the WS stack requires few additional setup steps. The suggested approach is to identify a single test to run; before actually running the test, manually start a target container in debug mode and specifying the proper port offset and server configuration (have a look at the arquillian.xml decriptors in the testsuite). Then run the tests with -Dserver.home=... option pointing to the home dir for the server currently running.