Bug Fixes in ReadyAPI 2.5

When a composite project was created on Windows computers, it was impossible to successfully open this project on Linux computers because ReadyAPI saved paths to resources incorrectly. (RIA-8302)

When you ran the second instance of ReadyAPI, it displayed an error message informing that the dashboard database is corrupted. (RIA-8474)

Due to conflicting dependencies in libraries used by ReadyAPI, it was impossible to use the Swagger Compliance assertion on macOS computers. (RIA-8562)

In some cases, when you created a project by using a Swagger definition, ReadyAPI could not create a proper payload for REST requests. (RIA-5408)

In some cases, ReadyAPI wrongly treated parameters when you were refactoring definitions based on a Swagger specification. (RIA-8587, RIA-8827)

The Postman plugin could not import tests if a Postman collection was exported from the Postman standalone application. (RIA-8012)

ReadyAPI could start slowly if a workspace contained a great number of projects. (RIA-8027)

An error occurred if a composite project contained a REST resource with the settings name. (RIA-8556)

If a user disabled the Complete error logs option, the detailed report contained a non-informative error message. (RIA-7744)

When a user saved a composite project as a non-composite project, the resulting project file still contained attributes specific to composite projects. This caused ReadyAPI to treat this project as composite. (RIA-7276)

ReadyAPI required a SoapUI Pro license to work with composite projects. Now you can have any Pro license (SoapUI, LoadUI or ServiceV) to be able to work with them. (RIA-7175)

The command-line license manager allowed using a Floating license file for license activation. In this case, it showed a message informing about successful license installation, however you could not use the license. (RIA-5083)

When you selected a project with a WSDL definition in the Navigator, error messages could be posted to the log. (RIA-8077, RIA-8866)

If a user added an item to an array when editing a SOAP request in the Form editor, the resulting request contained only one array item. (RIA-8372)

SOAP Request test steps ran slowly if binary64 files were attached to them. (RIA-8530)

An error could occur when ReadyAPI was sending a large REST request. (RIA-8441)

In JMS Request test steps, SoapUI set a default value for the clientID JMS header. This value was not unique for each request and could cause errors. (RIA-8488)

If a user changed property names in a test step that had been cloned from another test step, the corresponding property names of the original test step were updated as well. (RIA-7252)

If a user renamed a test case in the Navigator, the name of this test case in the test suite editor was not updated. (RIA-8497)

OAuth authorization required a client secret even if the testing service did not require it. (RIA-8873)

SoapUI sent a wrong content-type header if a REST request used AWS Signature authorization. (RIA-7973)

The Column Path wizard created column paths using an incorrect syntax. As a result, the JSON Data Source test step worked incorrectly. (RIA-4103)

The Script assertion could be evaluated several times. As a result, errors could be posted to the log. (RIA-7331)

In some cases, ReadyAPI did not save the changes made to REST request properties in the request editor. (RIA-5144)

The Cross Site Scripting scan did not treat lines containing ï, ¿ and ½ symbols as a security vulnerability. (RIA-7671)

Secure showed an error message when the user tried to run the Weak Authentication scan on HTTP Request test steps. (RIA-7232)

Load tests that included JMS Request test steps worked incorrectly if the clientID JMS header was not specified in those requests. (RIA-7441, RIA-8645)

If you used a proxy server and ran a load test based on test cases containing a request to which the SSL keystore was applied, the load test failed. (RIA-9057)

If you ran a large load test that used the Oracle JDBC driver (ojdbc6_11g.jar), the Unauthorized usage of JIDE products error message could appear. (RIA-7759)

PDF load test reports did not contain information on the the number of agents. (RIA-7754)

Virtual services exported to WAR files always responded with the HTTP Status 500 – Internal Server Error status code. (RIA-8644)

If a response had a very long name, it was impossible to minimize the Response Content editor. (RIA-8848)

Sometimes, the JSON virtual service sent integer values in the scientific format. (RIA-7928)

A cloned response could have the same name as the original one. (RIA-7817)