Contributions
When will ReadyAPI ship with updated JRE?
Java version 16 hit End-of-Life in September 2021. There have been security updates to JRE 16.0.1 (now 16.0.2) which might have been included in one of the recent releases, but the five releases of ReadyAPI since December all ship with JRE 16.0.1+9-24. Java version 17, a long-term-support (LTS) version of Java, went GA in September 2021. When will the JRE that ships with ReadyAPI be updated? =========== ReadyAPI-3.10.2/jre/bin openjdk version "16.0.1" 2021-04-20 OpenJDK Runtime Environment (build 16.0.1+9-24) OpenJDK 64-Bit Server VM (build 16.0.1+9-24, mixed mode) =========== ReadyAPI-3.20.0/jre/bin openjdk version "16.0.1" 2021-04-20 OpenJDK Runtime Environment (build 16.0.1+9-24) OpenJDK 64-Bit Server VM (build 16.0.1+9-24, mixed mode) =========== ReadyAPI-3.20.1/jre/bin openjdk version "16.0.1" 2021-04-20 OpenJDK Runtime Environment (build 16.0.1+9-24) OpenJDK 64-Bit Server VM (build 16.0.1+9-24, mixed mode) =========== ReadyAPI-3.20.2/jre/bin openjdk version "16.0.1" 2021-04-20 OpenJDK Runtime Environment (build 16.0.1+9-24) OpenJDK 64-Bit Server VM (build 16.0.1+9-24, mixed mode) =========== ReadyAPI-3.30.0/jre/bin openjdk version "16.0.1" 2021-04-20 OpenJDK Runtime Environment (build 16.0.1+9-24) OpenJDK 64-Bit Server VM (build 16.0.1+9-24, mixed mode)3 years agoPlace ReadyAPI QuestionsReadyAPI Questions381Views0likes1CommentRe: Dark mode in ReadyAPI causes assertions to be unreadable
I think this issue might be limited to combining color blind mode with dark mode. When you have color blind mode set, it uses blue instead of green for passing tests and assertions. I suspect there is a separate color palette for color blind mode that did not get updated for dark mode, so the default foreground does not work with the color-blind background colors, thus the unreadable situation. When I toggle off colorblind tag, the assertions in dark mode are readable. SAMPLE with colorblind on: The assertions are unreadable in the pastel colors used with colorblind mode on, as shown above. Open properties and toggle off color blind mode, then re-run the tests... SAMPLE with colorblind mode off: Assertion fonts are readable with color blind mode off. There's still a UI bug with dark mode and color blind mode together, but at least I have a workaround.3 years agoPlace ReadyAPI QuestionsReadyAPI Questions791Views0likes1CommentRe: ReadyAPI 3.20.0 title bar prevents windows drag-to-top maximize feature
I'm talking about dragging the non-maximized window the top of one of my monitors, whether it is originally on that monitor or a different one. It is interesting that you mention moving from one screen to another, as this when I usually do this. For example, I am presenting in a virtual meeting, sharing my main screen. I have other windows that are not relevant to the moment on the screens of other monitors, so I can seen them, but it does not distract from the presentation I am giving. At a moment when I want to bring ReadyAPI into the presentation, I may grab it from one of the other screens and pull it to the main screen I am sharing. To have it take the entire monitor, I would simply drag it to the top, causing it to maximize when I release it. When I do this with any other windows application, dragging the non-maximized window to the top of the screen causes the window to maximize, and this has been true for ReadyAPI, as well, until ReadyAPI 3.20.0. As a workaround, I can maximize ReadyAPI 3.20.0 windows by selecting the maximize icon in the upper right; or I can use the keystroke combination [WindowsButton]+[UpArrow].3 years agoPlace ReadyAPI QuestionsReadyAPI Questions432Views0likes0CommentsDark mode in ReadyAPI causes assertions to be unreadable
I have a problem viewing assertion results in Dark Mode. Once the assertion has run, it is unreadable... just a blank strip colored pale blue or pink, depending on whether the assertion has passed or failed, as in this example. I see this in ReadyAPI 3.10.2 and 3.20.0.Solved812Views0likes2CommentsReadyAPI 3.20.0 title bar prevents windows drag-to-top maximize feature
Something seems to have changed with the title bar in ReadyAPI 3.20.0 for Windows. It now does not show up with the theme coloring for windows title bars, but retains the same color as the rest of the app. Ok, no big deal, I can deal with color changes. But there is also a functionality change: When I try to drag the window by the title bar to the top of my screen, my usual way to maximize a window I'm working with, it doesn't maximize. The drag-to-top-to-maximize worked in all prior versions of ReadyAPI, including 3.10.2. I've tried uninstalling and re-installing to no avail. Is there a benefit we get for this change to remove the title bar drag-to-top-to-maximize functionality? Is there a setting to restore the functionality?3 years agoPlace ReadyAPI QuestionsReadyAPI Questions493Views0likes2CommentsRe: How to prevent ReadyAPI from randomly changing how it stores empty XML elements?
HeyJoostDG! Setting properties locally sounds like an useful feature. Moving properties out of the project source would be a good way to avoid properties value changes that happen during each run, something I have done until now by using cleanup scripts. The properties I'm talking about are mostly (all?) in properties test steps, which unfortunately don't offer any way to store locally. Not sure it is worth the hassle to retrofit existing projects, though that script should help! I will play with this local storage idea in new projects, and I may change my pattern for setting up test properties in the future to use property types that support storage in the user-local workspace. Thanks for alerting me to the local storage option! JR3 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.2KViews0likes0CommentsRe: Dark Mode now available in ReadyAPI
I have a problem viewing assertion results in Dark Mode. Once the assertion has run, it is unreadable... just a blank strip colored pale blue or pink, depending on whether the assertion has passed or failed, as in this example. I see this in ReadyAPI 3.10.2 and 3.20.0.3 years agoPlace ReadyAPI QuestionsReadyAPI Questions861Views0likes1CommentRe: Swagger compliance assertion seems to be prefixing url with a local path
I don't know how the corruption got introduced to the Swagger Compliance Assertion. Editing the URL was to no avail, but I could work around the problem by removing the assertion and then adding a new one. My guess is that the corruption happened when I updated the project definition. There's a bug there somewhere, I think, but not going to worry about it for now.3 years agoPlace ReadyAPI QuestionsReadyAPI Questions589Views0likes0CommentsSwagger compliance assertion seems to be prefixing url with a local path
I allowed ReadyAPI 3.20.0 to generate tests for a new Spring Boot application, pointing it to the swagger api-docs for the service. The generated Swagger Compliance assertion fails with a message that I find a bit confusing: "-> Swagger Compliance check failed: [Illegal char <:> at index 52: C:/Program Files/SmartBear/ReadyAPI-3.20.0/bin/http:/myhost:30102/myappname/v2/api-docs]" The response content it is evaluating is: My Spring Boot App w REST API! Date is now 2022-01-20T01:32:14.189791Z I note two strange items in the swagger compliance check error message: 1. Why is it prefixing the URL with the local path to the ReadyAPI installation's bin folder? 2. Why does the message show the URL with only a single slash? The colon '<:>' that is close to index 52 is the second one in the error message's broken URL, rather than one in the response content. Whether or not this is a real compliance failure (I am guessing that it wants JSON or something), the assertion failure message seems to be messed up and is therefore not helpful. Am I missing something obvious?Solved580Views0likes1CommentRe: How to prevent ReadyAPI from randomly changing how it stores empty XML elements?
So the solution really is: You can't prevent it. Whenever you upgrade, the new version of ReadyAPI will do whatever it wants with regard to the empty XML fields... some versions will generate a beginning tag and end tag <tag></tag>, then the next version may decide to use the shortcut <tag/>, and the version after that may revert to the expanded <tag></tag> again, and there is nothing to be done but allow it. 😞3 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.3KViews1like2Comments