Update of Log4J, Java 11 as minimum requirement, Upgrade to Selenium 4.

XLT 6.0.0

See here for a complete list of all changes.


Version 6 is a major release of XLT. It comes with new features, which introduce breaking changes, hence the change of the major version number.

We want to thank OTTO for supporting this release and all the testing help they have given us.

Java 11

XLT now requires Java 11 or higher to run. This means you will need a JDK 11 (or later) on your development and load test machines. Please be aware that we don’t fully support all the latest JDKs, such as Java 17, yet. You can give it a try, but some removed features or missing library support might show up. Any feedback appreciated.

Selenium 4

The Selenium team has released Selenium 4.x. Please see their blog to learn what is new and what changed. XLT upgraded to Selenium 4.

Although Selenium 4 is intended to be a drop-in replacement for most users, there might be things that need to be migrated. See the migration guide. Furthermore, some constructors of XltChromeDriver and XltFirefoxDriver that were marked as deprecated for a while have been removed.

Logging Framework Update

The previously used logging framework log4j 1.x has been replaced with the latest log4j 2.x. log4j2 brings not only performance improvements, but is also not vulnerable to any known security issues.

With this upgrade, XLT has been made completely agnostic to the underlying logging framework. XLT will now log through the logging facade SLF4J. This means that some features that made direct use of the log4j APIs are no longer available. See the following list of incompatible changes:

  • The type of XltLogger.runtimeLogger changed to org.slf4j.Logger.
  • The timers.csv files, the data files where XLT stores its measurements to, aren’t rolling over any longer. So there is always only a single timers.csv file for each virtual test user.
  • When running test cases directly from your IDE, the logging framework is no longer automatically configured by the file <testsuite>/config/dev-log4j.properties, but by a new file in the classpath. See the migration guide below for more details.
  • The log4j2 configuration files require a different property syntax.
  • The Javascript debugger that logs the executed Javascript statements is not available at the moment.


The documentation is no longer part of the XLT distribution. Please now refer to the online version.

Credential Security

Credentials may be passed as part of the user information in URLs, such as in https://user:pass@host/. To preserve the confidentiality, XLT now makes substantial efforts to remove credentials from any URL it records. This includes the data in the timers.csv files and the result browser. This feature is enabled by default, but can be disabled if needed:

com.xceptance.xlt.results.data.request.removeUserInfoFromURL = true

Test Suite Migration

As outlined above, XLT 6.x comes with breaking changes. In order to migrate your test suites, you will need to perform the following steps:

Update to Java 11

Ensure the latest JDK 11 is installed on all your development and load test machines. You have to reconfigure your IDE to use Java 11 to compile and run your test cases. If your test suite comes with an Ant/Gradle/Maven build file, adjust it to use Java 11 as well.

Update the Logging Configuration

Copy <xlt>/samples/testsuite-template/config/log4j2.properties to the config folder of your test suite and adjust it to your needs. This file replaces the old log4j.properties. It will be used when executing a load test.

Copy <xlt>/samples/testsuite-template/src/log4j2-test.properties to the sources of your test suite and adapt it as needed. This file replaces the old dev-log4j.properties and will be used when executing your scenarios during development. Make sure to place it in a folder from which it gets automatically copied to the output folder when building the test suite. Log4j2 will only load it from the classpath.

Let’s assume your project is Maven-based. If it uses the standard Maven directory layout, copy log4j2-test.properties to src/main/resources (if your test scenarios live in src/main/java) or to src/test/resources (if you prefer having your scenarios in src/test/java) and you should be all set.

When your project uses a custom directory layout, such as src for the source code and classes as the output directory, copy log4j2-test.properties to src. Furthermore, you need to adjust the pom.xml. You have to tell Maven where your resources can be found and which should be copied:


    <!-- tell Maven where resources can be found -->
                        ensure only properties are copied to 
                        the output directory -->

For non-Maven projects, make similar adjustments to get log4j2-test.properties copied to the class path.

Finally, delete the log4j 1.x configuration files config/log4j.properties and config/dev-log4j.properties.

Fix Compile Errors

If there are still references to log4j 1.x in your code, replace them by SLF4J. In case your code uses Selenium classes that do not exist any longer in Selenium 4.x, rework your code for Selenium 4.x. If you made direct use of XltChromeDriver or XltFirefoxDriver, make sure to use only the non-deprecated constructors or builder methods.

Rebuild Test Suite

Even if your source code is not affected by the API changes, you have to completely rebuild your test suite. When you encounter strange runtime errors later, make sure that this step was performed.

Test Your Scenarios

Now it’s time to check if everything works as expected. Start by running the test scenarios from your IDE. They should run and finish with the expected results. Make sure the usual debug console output is visible as well. Use this opportunity to fine-tune the dev mode logger configuration if needed.

After that, perform a small load test. Check the results and verify the output in all log files.

AWS AMI Retirement Notice

Xceptance provides machine images for Amazon’s Elastic Compute Cloud with XLT installed and configured for use as load agents. As part of our regular clean-up process, we will retire AWS AMIs older than XLT version 5.6.x on April, 1st 2022. If you need an older version, please build your own AMI (see here for more details) or copy the respective AMI to your own AMI registry in time.

As a notice for the future: Xceptance will not guarantee that provided AMIs (and, in the future, Docker images or images for other cloud providers) are available forever. We strongly encourage you to migrate to the most recent version frequently. If you need a particular setup maintained for a longer period of time, please talk to Xceptance and consider a support contract.

Last modified May 25, 2022