Version History

• Database update: VirtServer’s internal database has been upgraded to H2 version 2.3.x, and older, vulnerable H2 jars have been removed from the VirtServer installer. For more information, visit this page.

• VirtServer 3.23.0 compatibility: Now compatible with ReadyAPI 3.55.0.

• JDK update: VirtServer now uses JDK version 17.0.12.

• Memory management improvement: An issue related to memory usage has been resolved. After undeploying large services, the heap memory usage now returns to within 10% of the baseline levels observed at startup.

• /tmp directory cleanup: Previously, the /tmp directory was not being cleared when virtual services were stopped, causing it to fill up and disrupt future service startups. VirtServer now clears all temporary folders created during virtual service deployment upon graceful shutdown.

• Brotli library error: Users upgrading to VirtServer 3.21.0 encountered a java.lang.UnsatisfiedLinkError: Failed to load Brotli native library error, which prevents VirtServer from starting. This issue occurs because environments like RedHat Linux 9 do not have exec rights in the /tmp folder, preventing the Brotli library from running. As a result, the Brotli library cannot be written to the temporary directory or executed.

  To help users, an error message has been added to the logs and startup console. This message explains the issue and provides a solution: use the java.io.tmpdir system property to specify a directory with the required read, write, and execute permissions. For details on the workaround to this issue, visit: Troubleshooting Brotli Library Error.

• License retention issue fixed: When updating from VirtServer 3.18.0 to 3.19.0 or later, licenses were not retained. Starting with version 3.19.0, license information is stored in <home-path>/.virtserver instead of .readyapi. This issue has now been resolved, ensuring licenses will persist after updates and restarts.

• VirtServer now supports the conditional match dispatch strategy in ReadyAPI. To learn more about conditional match, visit this page.

• Deploying large project files (>400MB) using VirtServer CLI to VirtServer on the same machine can cause timeouts. To address this, we have made timeouts configurable by adding a vmoption.

• When VirtServer runs as a service, it will now automatically create the database and add a default user. This improvement ensures that VirtServer can start automatically as a service without requiring manual user setup.

• VirtServer 3.22.0 now supports ReadyAPI 3.54.0.

• We have updated the JDK to version 17.0.11.

• When the CLI detects that the connecting VirtServer is OIDC enabled, it will make a Client Credentials request to the OIDC provider URL. Using the provided client credentials, it allows a machine to access VirtServer with either admin- or regular user-level privileges to perform tasks.

• The VirtServer CLI can now function through a proxy for logging in, installing licenses, and managing virtual servers.

  At the application level, VirtServer can utilize ReadyAPI's proxy configuration, provided ReadyAPI is installed and configured on the same machine as VirtServer.

• We now offer settings configurations through arguments or parameters that allow customers to add their own Okta user groups for Admins and Users.

• Fixed a bug that allowed users to log out of their Okta session if they tried to log in as an Okta user without any group. The message "Error. VirtServer requires users to be part of application-specific groups. Please contact your OIDC Administrator for support." is shown, and the user can log out of their existing Okta session to log in again and be authenticated anew.

• We added support so that Okta tokens can be automatically refreshed before expiration ensuring uninterrupted access to the application. This is based on the token expiry settings in Okta.

• We have improved the error messages.

• We released Jenkins Plugin 1.19.0 which requires Jenkins 2.440.3 or later. This is part of the ongoing maintenance to update existing libraries and plugins to the latest versions of the product.

• VirtServer now supports customers using OIDC for user authentication and authorization in version 3.20.0 with the following additions:

  • User authentication for VirtServer Web UI and CLI, as well as the ReadyAPI VirtServer panel. When VirtServer is configured in a customer's Okta environment, you can log in using PKCE flow to VirtServer Web UI or Device Login for CLI.

  • OIDC support for user management for the Jenkins + Maven plugin will be included in future releases.

  • License installation for SLM on-premise 2.1.1 (where OIDC is configured for SLM on-prem license server) is also part of this release for Windows, Linux, Platform Independent, and Docker.

• We've updated DropWizard in VirtServer to version 4.x. Jetty 10.0.x has introduced stricter SNI host checking, which may cause issues when making requests over HTTPS. You can read more about here. Visit the VirtServer Settings page for documentation on configuring this setting.

• We resolved a bug where the grace period wasn't functioning as expected, allowing Virtual Services to be started during the grace period when only virtual services that are already running should be operational during this time.

• Licenses are now installed in the $HOME/.readyapi directory instead of $HOME to prevent license activation issues some users faced after the latest ReadyAPI update.

• We fixed an issue causing VirtServer to lose its license after stopping VirtServer as a service and starting it as an application.

• We addressed an issue causing the request body in the Transaction log in ReadyAPI - Virtserver panel to be empty when an incoming request to a virtual service in VirtServer had Content-Type: application/x-www-form-urlencoded.

• We fixed an issue causing problems when changing the response delay value, where sometimes the value wouldn’t update.

• We’ve updated a few third-party libraries to make the product even more reliable and secure. Please see here for the full list.

• We enhanced security by migrating SLM authentication to use Auth0.

• We improved the Docker container shutdown behavior, sending a call to the unlock endpoint of the SLM server for correct license unlocking during product shutdown. License is made available immediately for next user.

• We made changes to license installation when ReadyAPI and VirtServer licenses are available in the same SLM server.

• We fixed an issue with SLM, ensuring the license reinstalls correctly upon product restart.

• If an error occurred while entering a new user, the 'Add User' button would remain disabled even after it was rectified. This issue is resolved.

• We added audit log detail displaying the last ping during the grace period. It will help to investigate issues with the SLM server.

• We resolved a problem where setting response delay from the Behavior tab did not update correctly.

• We’ve updated a few third-party libraries to make the product even more reliable and secure. Please see here for the full list.

• ReadyAPI is now updated to support VirtServer CLI 1.18, incorporating its latest capabilities.

• Added a new CLI command Virts -stopall, which can be selected to stop a working virtual service.

• We added a new feature to view and download the Virtual Service Transaction Log through the Web UI. This feature covers SOAP and REST services, with support for other protocols planned in future releases. Read more about transaction log.

• We added a diagnostic probe which adds the network probe responses when creating a diagnostics report. This helps to verify VirtServer is able to see network endpoints such as SLM License servers.

• We updated support for matching TCP requests using Groovy scripts at service level, a feature introduced in ReadyAPI 3.47. Learn more about matching TCP requests.

• Fixed a bug introduced in VirtServer 3.17, which affected the behavior of dispatch parameters.

• VirtServer is updated to align with ReadyAPI 3.49 and the latest version of Microsoft Excel in data-driven testing (suporting .xlsx).

• Updated some libraries as part of ongoing maintenance work.

• From October 2023, we won't provide file-based licensing. Instead, we will replace it with SmartBear ID-based licensing - With VirtServer 3.17.0, we extend support for SmartBear ID-based licenses hosted on SmartBear licensing servers. You can now specify your access Key in the license installation process and request a license, once is it made available and assigned on https://manage.smartbear.com/. As we approach the October milestone, we're actively encouraging customers to transition over. Now is the time to start planning that transition. You should immediately engage with your SmartBear Account Manager to understand the steps involved in transitioning and getting started. Please read here to learn more.

• As part of our product maintenance progam, we are also upgrading the underlying H2 database to the latest version V2.1. The upgrade will happen as part of your next installation or upgrade and will migrate your data and users without you needing to do anything. However, we understand that you may have questions or in the event of the upgrade experiencing issues, please contact support if you need help before of during the upgrade process. You can also request a technical session with our Solution Engineering team if you would like some help. Please contact your SmartBear Account Manager to arrange.

• From October 2023, we won't provide file-based licensing. Instead, we will replace it with SmartBear ID-based licensing - SmartBear ID-based licensing (also known as SmartBear License Management or SLM), is a new license management option that we started using in ReadyAPI 3.8.1. Support for SmartBear ID-based licenses is now being added to VirtServer 3.16. It is more reliable and convenient than the license type used in the previous product versions. As we approach the October milestone, we're actively encouraging customers to transition over. Now is the time to start planning that transition. You should immediately engage with your SmartBear Account Manager to understand the steps involved in transitioning and getting started. Please read here to learn more.

  • Support for SmartBear ID-based licenses is starting with offline (Customer on-premise) deployment in Q1 2023 (where the customer hosts the license server on-premise). We will add support for online (SmartBear hosts the license servers) later in 2023.

• As part of our product maintenance program, we updated the following:

  • JRE to jdk-17.0.6.

  • We’ve updated a few third-party libraries to make the product even more reliable and secure. Please see here for the full list.

• We fixed a bug where the transaction log was not working in docker for medium-large responses (VSERV-1163).

• We updated CLI to 1.16 in support of VirtServer 3.16.

• We updated OpenSSL3 to latest version in Docker in response to CVE-2022-3602, CVE-2022-3786.

• Please Note - Windows, Linux and Platform Independent versions remain at 3.14.0 as these are not impacted.

• We resolved an issue where some customers using fixed licenses in private networks saw virts stopped after 20 minutes. An error message used to pop up saying that the license was not installed or expired.

• We also supported a request to enable a download of csv and pdf file of VirtServer Audit Log with or without license.

• We updated commons-text to 1.10 in response to CVE-2022-42889.

General

• We upgraded to Java to 17.0.4.1 (VSERV-1014).

• We recommend installing VirtServer into a new folder location (rather than updating the current) and manually deleting the folder for the previous version following recent discussions with customers upgrading to VirtServer 3.13.0. We do this to enable a cleaner installation and to avoid possible issues following our recent upgrades to Java 17.0.4. This is mainly related to Linux upgrades but we recommend this approach for all other customers also.

Admin

• If you prefer running the installer in unattended mode -q, you can configure using system properties -Dservice.install and -Dservice.autostart (VSERV-935).

  • examples:
    VirtServer-x64-3.13.0-SNAPSHOT.sh -q -Dservice.install=true will install the service, requires that the user is root.
    VirtServer-x64-3.13.0-SNAPSHOT.sh -q -Dservice.autostart=true will install the service and configure it to autostart when the operating system boots.

• We updated Helm Chart guidelines to make it easier to manage port-numbers for virtual services easier access (VSERV-883).

Security Updates

• We addressed the vulnerabilities that were detected within the har-java project through the inclusion of the jackson-databind-2.12.2 dependency (VSERV-844).

• We added help instructions when no command is specified in a CLI call (VSERV-957).

• We added project identfier to deleteall in CLI so that virts in a project are removed (VSERV-956):

  --deleteall /path/to/projectfile or just --deleteall to delete everything.

• We added support for zipped composite projects in CLI (VSERV-842).

  • You can send in a zipped project with -d project-file-name, or --deploy project-file-name.

  • You can send in a zipped project to --deployall.

• We extended the capabilties of CLI to support communication with VirtServer using HTTP (where previously CLI only supported HTTPS).

• You can activate, deactivate, and print active license information for a connected VirtServer.

• You require Java 17 for the CLI.

UI Improvements

• ‘Generate Report button’ is now deactivated when there are no virtual services deployed (VSERV-850).

• WebUI password change and validation improved ( VSERV-255 and VSERV-815).

• WebUI tables made easier to read (VSERV-806 and VSERV-805).

• Popup to validate and confirm the change of Groups action (VSERV-789 and VSERV-790).

• Notification popup behaviour improved when a user switches between the table and other screens (VSERV-394).

• It is possible to add a Response Delay in MS to virtual service in VirtServer Web UI. This will be overwritten if the virtual service is downloaded/replaced from ReadyAPI. (VSERV-884)

Click the image to enlarge it.

Working with copies of Virtual Services

• It is possible to deploy several virtual services with the same name but different ports on one VirtServer (VSERV-778). These is now a new option --clone or short -c that can be added to the deploy command. This option is not allowed to be combined with --replace or short -r. That will cause an error.

  When deploying, if there already is a deployment from this virt on the server, it will do one of three things:

  • If neither --replace or --clone is present, an error will occur saying to use --replace is needed to replace. (I see now that this message could be updated to mention --clone). No changes will be performed at all.

  • If --replace is present, all deployments based on that virt will be replace. The meta data for these (like port) will stay the same.

  • If --clone is present, a new deployment will be created based on the same virt. All old deployments will stay the same.

Access Virtual Service History

• It is possible for admins to download HAR logs from the web page (VSERV-753):

Click the image to enlarge it.

• It is also possible for admins to send a request to an endpoint to download HAR logs (VSERV-873). There is an endpoint POST /api/v1.2/har/files that lets the user download specified har-logs:

  • Sample JSON Request

  
  [
  "New JSON API-20210629_111739.har",
  "New JSON API-20210707_120708.har",
  "New JSON API-20210707_120722.har"
  ]
  

  • List of files can be located in the Transaction Log Screen in WebUI:

  

  Click the image to enlarge it.

  • Response will always return a ZIP file (even if there is only a single file).

  • Response will return all files found. If files are not available or deleted, these will not be returned.

  • Each request is logged in the Audit Log.

Request Validation Improvements

• Request Validation can determine a request valid based on Query Parameters (VSERV-759) and Header Parameters (VSERV-764) as described here: https://swagger.io/docs/specification/describing-parameters/#query-parameters and https://swagger.io/docs/specification/2-0/describing-parameters/#header-parameters

• Multiple values are accepted in the ‘Accept’ header (VSERV-802).

• $ref in ‘anyOf’, ‘allOf’ and ‘oneOf’ are resolved before running Request Validation on a body for OAS3 and Swagger2 (VSERV-794).

• 415 response is returned if a request body is not JSON (VSERV-781).

Security and Maintenance

• Upgraded to JDK17 (VSERV-922).

• Upgraded Spring to 5.3.20 (VSERV-871).

• Upgraded Liquibase to 4.11.

• Launched HelmChart for Kubernetes Deployment GitHub - SmartBear/virtserver-helm: An example of a helm chart that can set up virtserver in kubernetes

Issues Resolved

• Fixed issue where JMS Virtual Service could not be started when start script executed after the connection is established (VSERV-826 and RIA-19121).

• Improved CLI issues - User used to get stuck when trying to create a user where name already exists (VSERV-393), trying to edit a user that doesn't exist (VSERV-313), makes a mistake in -pw flags when using "setservername" operation (VSERV-309) - now resolved.

• Fixed issue where CLI failed to deploy with composite projects containing extra directories (VSERV-841).

• Improved CLI error handling (VSERV-300 and VSERV-875).

Automocking Improvements

• In support of SwaggerHub automocking improvements, Request Validation has been added to VirtServer. Based on the API definition document and when request validation is enabled in SwaggerHub, incoming requests to the virtual service can be validated against the schema and return valid (200) or invalid (400, 422) responses. The following table describes the expected behaviour for valid and invalid requests.

Click the image to enlarge it.

• Added support for OAS3 / Swagger2 content negotiation, path templating, $refs for examples, and schema in OAS3 / Swagger2.

Groups

• Groups now show an error message when a regular user tries to add or delete a tag on a Grouped virtual service where a user is not a member of the same Group.

• Groups now allow typing usernames in the "Select Users" dropdown when configuring a new Group and seeing the list of users filtered accordingly.

• Users can search by GroupName and only have the APIs under that GroupName show up.

• When a virtual service is assigned to a group, 'Assigned to Group' event will be logged in the Audit logs.

• We have improved validation and confirmation when removing a user from a Group.

General

• WebUI tables only present if there is data to show or have hover state only when there is further information to show.

• Introduced Typescript in VirtServer WebUI.

• To increase the performance of VirtServer, the transaction log can be switched off if it is not required.

• VirtServer log (virtserver.log file) now contains more information about the virtual service where an ERROR/WARN happened. This will assist in identifying which virtual service is affected and whether a warning or an error.

VirtServer CLI

• VirtServer ships with the command-line utility version 1.13.0. the latest features in this version of the utility are outlined below.

• Added --version command to VirtServer CLI.

• Fixed CLI bug where it failed to deploy with composite projects containing extra directories.

Other Fixes

• Fixed issue where TCP virtual service did not record routed requests when deployed in VirtServer.

• Fixed issue where previous login session from a browser expires when the same user logs in from a different browser.

• The utility now supports the --version (-v) command. It prints the version of the command-line utility.

• When you used the utility to deploy a virtual service from a composite project, the utility looked for the settings.xml file in the wrong directory. Now, it is fixed.

• Log4j was updated to version 2.17.1.

• Now, you can get the diagnostic report from the user interface.

• The diagnostic report now also includes the audit log.

• Now, when you view the audit log in the web UI, you can show only Login or Logout messages.

• VirtServer ships with the command-line utility version 1.12.0. What’s new in this version of the utility, see below).

• We have fixed a number of bugs.

• We’ve improved the messages command-line utility posts to the console output. Now, the messages contain the [ERROR] prefix for the error messages and [INFO] for all the rest messages.

• We’ve updated exit codes. Now, in all the cases when the utility stops working unexpectedly, it returns 1.

  You may need to update your automations that rely on exit codes.

• The new command - deployall - adds all virtual services from a project.

• The new command - deleteall - removes all virtual services from VirtServer.

• We've updated third-party libraries to make our product even more secure and stable.

• The new version introduces user groups – a way of managing user permissions in VirtServer. They allow you to make certain virtual services only available to a limited group of people.

  • As an administrator, create user groups and add users to them.

  • Assign virtual services to groups so that they are available only to the users of the respective groups.

• Log4j was updated to version 2.16.0 to mitigate the CVE-2021-44228 and CVE-2021-45046 vulnerabilities.

• The username for LDAP connection can now be entered without domain prefix.

• We have updated the ReadyAPI dependency to 3.20.0.

• We have fixed a number of bugs.

• The new version includes a fix of the Apache Log4j CVE-2021-44228 vulnerability issue and adds the -Dlog4j2.formatMsgNoLookups=true flag.

• We updated the ReadyAPI dependency to 3.9.2.

• VirtServer could not start when you installed it as the root user.

• We improved the stability of the product when you run a bunch of virtual services at once.

• Starting from 3.6.0, VirtServer uses a single database for storing all its data.

  We recommend that you make a backup of the user database located in the <user home directory>/.readyapi/virt-server folder.

• We updated the ReadyAPI dependency to 3.8.1.

• We improved the stability of VirtServer when it handles virtual services with the enabled autostart option.

• We updated the web interface of VirtServer.

• The Audit Log now contains login and logout events for users.

  This change will make the audit log unusable if you try to downgrade from 3.5.2 to an earlier version. We recommend that you make a backup of the user database located in the <user home directory>/.readyapi/virt-server folder.

• VirtServer will try to reconnect to the floating license server when the server is restarted.

• We fixed a bug where the request count did not update properly in the UI when a virtual service was under heavy load.

• Now VirtServer uses the latest version of the PostgreSQL JDBC driver.

• Since VirtServer 3.4.6, the PostgreSQL JDBC driver is always installed. The related option has been removed from the installation wizard.

• The Web UI now uses the latest version of the React library.