Bug Fixes in Ready! API 2.0
This topic describes the changes made to Ready! API 2.0.
Overall Bug Fixes
An incorrect activation file specified on the last step of offline license activation could corrupt the license. (RIA-225)
Some proxy configurations on Mac OS X 10.11.6 prevented license activation. (RIA-127)
The
lastOpened
value in thesettings.xml
file could cause conflicts when merging composite projects. (RIA-486)Renewal licenses installed beforehand could sometimes fail to activate. (RIA-673)
If no SoapUI NG Pro license was active, clicking the Reporting button on the Ready! API toolbar opened the License Manager dialog instead of displaying a warning informing the user about the missing license. (RIA-834)
Some firewalls blocked downloading of the ready-api-soapui.jar file from the SmartBear Maven repository. (RIA-1960)
Switching to a workspace with a Ready! API project that uses the Git plugin could cause Ready! API to stop responding. (RIA-1984)
Ready! API could fail to open some large composite projects. (RIA-2636)
SoapUI NG Bug Fixes
Ready! API could stop responding when working with large JSON requests or responses. (RIA-81, RIA-136)
The SOAP VirtResponse test step could sometimes incorrectly return the 403 error. (RIA-157)
There was a typo in the New Project dialog. (RIA-166)
Ready! API could stop responding when you opened a large SOAP request in the Form editor. (RIA-302)
Sometimes, JSONPath expressions with property expansions failed to return the correct match. (RIA-318)
The DataSink test step did not get all data from load tests. (RIA-379)
The resource path value in REST requests could be reset upon restarting Ready! API. (RIA-444)
Sometimes, the response header could be displayed incorrectly in the Raw request editor. (RIA-575)
Projects with REST test steps created in Ready! API 1.8.0 or 1.8.5 could use wrong REST resources when they were opened in Ready! API 1.9.0. (RIA-592)
The element order in the XML editor differed from that in the Form editor. (RIA-602)
Ready! API displayed the Content-Length header in the Response editor for responses with the
204 No Content
HTTP response status. (RIA-608)Incoming and outgoing WSS configurations were recorded incorrectly. (RIA-616)
Requests with a highly nested payload were not opened properly. (RIA-627)
The Add and Remove buttons were missing in the JSON data source editor. (RIA-648)
The connection to the DataSink test step database was sometimes reset when the environment was changed. (RIA-681)
Data source properties created in SoapUI 4.6.4 were discarded when the project was opened in Ready! API. (RIA-692)
The XQuery Match assertion could cause an exception when asserting a response from the SOAP VirtResponse test step. (RIA-699)
Custom request headers were not added to some requests during load testing. (RIA-703)
Sometimes, the JSONPath Regex Match assertion did not save the text of a regular expression. (RIA-769)
Quotation marks (
"
) enclosed the data returned by the Excel DataSource test step. (RIA-795)Sometimes, Ready! API failed to open a test case or test suite editor when running on a computer where Oracle Single Sign-On was used. (RIA-800)
The Send Mail test step could not send messages through Google Mail. (RIA-816)
PUT requests were changed to GET requests after following the 302 redirect. (RIA-879)
The SSL Info response tab in the HTTP Request test step was always empty. (RIA-963)
The Add Assertion dialog used a lot of CPU time and RAM. (RIA-977)
Sometimes, Ready! API failed to open the correct request for projects created in version 1.7 or earlier. (RIA-1016)
In some cases, if the Assertion test step was used in a test launched by using TestRunner, the test run returned the -1 error code despite the fact that it was successful. (RIA-1141)
When reloading a project or importing a project that already existed in the workspace, Ready! API reset the environment to the default value. (RIA-1386)
Updating a Swagger definition created duplicate
TEMPLATE
parameters. (RIA-1502)Some proxy configurations prevented Ready! API REST discovery from working. (RIA-1531)
Sometimes, the OpenID authorization scope header was not sent in an OAuth 2.0 authorization request. (RIA-1945)
Under certain conditions, Ready! API sent a request with the
GET
method instead ofDELETE
. (RIA-1961)The Groovy debugger did not stop at breakpoints in test cases run by the Run Test Case test step. (RIA-2045)
On rare computer configurations, transaction log notifications could cause Ready! API to crash. (RIA-2050)
JSON files containing items with the "null" name could not be displayed in the JSON editor. (RIA-2404)
Composite projects containing reports of certain types could not be saved. (RIA-2536)
The XML editor was not properly updated with the changes made in the Form editor. (RIA-2537)
You could not run a project with multiple JMS Request test steps by using TestRunner on Linux computers. (RIA-2632)
The
$
symbol in the path to a JSON object caused the expression to returnnull
. (RIA-2667)
Secure Bug Fixes
XPATH Injection Sample Project failed if it was run from the Security Test Runner. (RIA-1647)
Ready! API skipped the Weak Authentication scan during security tests. (RIA-2564)
LoadUI NG Bug Fixes
LoadUI Agent could not simulate a lot of VUs if the responses from the server were large. (RIA-76)
LoadUI Agent displayed an invalid warning on startup. (RIA-250)
Load reports had an incorrect request failure ratio. (RIA-481)
The Average number of requests field in load test reports showed incorrect time units. (RIA-553)
Assertion failures in tests running on a remote agent were not displayed in the LoadUI NG log. (RIA-1076)
When a user was viewing load test statistics for long-running load tests, Ready! API could stop responding. (RIA-1602, RIA-2388)
Sometimes, failed test steps were represented incorrectly in load test reports. (RIA-2004)
Trailing spaces in requests created by using the JMS request test step during load testing were removed. (RIA-2550)
Sometimes, the Test Step Metrics table displayed incorrect values for distributed tests. (RIA-2634)
ReadyAPI Virtualization Bug Fixes
ServiceV used more memory than necessary to simulate virts. (RIA-243)
Requests sent to a service were sometimes modified, which made them invalid for the service. (RIA-804)
Path values were not added to the request context when the Routing mode was enabled. (RIA-850)
Responses compressed by using gzip could not be viewed in the XML or Outline editor. (RIA-1682)
Sometimes, multipart responses had incorrect Content-ID values for the response parts. (RIA-1734)
Attachments sent to a virt were sometimes not received completely. (RIA-2613)