SoapUI 5.9.0 Installer.app does not open on macOS Ventura 13.7.5
Hello, I’m trying to install SoapUI 5.9.0 Open Source on my MacBook Pro (Intel) running macOS Ventura 13.7.5. Java 11 (Temurin) is installed and works correctly (java -version shows version 11.0.28). However, when I try to launch the SoapUI 5.9.0 Installer.app from the DMG package, macOS shows the message: “The application ‘SoapUI 5.9.0 Installer.app’ can’t be opened” The icon is displayed with a “prohibited” sign. It seems like the installer is not recognized as compatible, even though release notes mention Ventura compatibility starting from version 5.7.1. Is there an updated installer for macOS Ventura (Intel)? Should I use the .tar.gz / .zip distribution instead of the DMG? Has this issue been officially confirmed for Ventura users? Thanks in advance for any guidance.
How to escape ampersand in Property Expansion?
Hi, In our TestCases, we use properties as values for SOAP requests in the following way: <com:name>${#TestCase#currentName}</com:name> This mostly works fine, but in some cases the property values contain an ampersand (&) character. This then leads to an incorrect XML and thus invalid SOAP Request: <com:name>Fencing & Security</com:name> The expected behaviour would be that SoapUI escapes the invalid character to create the following element: <com:name>Fencing & Security</com:name> When assigning the value to the element using a separate Property Transfer test step, this is correctly done (the value is escaped). The problem is that we set all the properties using a Groovy Script before running the request, which makes using property expansion in the request by far the easiest way to assign all values. Is there a way to use property-expansion that does escape special characters when used in XML?
No Fluff, Just Real Stuff - DevRel Newsletter July edition here!
Hi everyone, The latest issue of No Fluff, Just Real Stuff, our DevRel newsletter, is here! In this edition, we’re talking about the launch of the SmartBear MCP server, share the latest release update information for SoapUI, and a link to our recent Contract Testing: Debunking the Doubts webinar and much more. As always, we hope you find it’s packed with useful updates and practical insights! Got feedback or want to be featured in a future edition? Drop us a line at devrel@smartbear.com —we’d love to hear from you. Enjoy the read! —Frank, Jo & Yousaf. The SmartBear DevRel Team"Clone interface" between projects not working
Hi, Recently I tried to copy soap interface between projects using both context menu and Ctrl+drag'n'drop, but each and every time I ran into this error: Wed Jul 02 10:05:36 CEST 2025:ERROR:java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because the return value of "com.eviware.soapui.impl.support.AbstractInterface.getTechnicalId()" is null java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because the return value of "com.eviware.soapui.impl.support.AbstractInterface.getTechnicalId()" is null at com.eviware.soapui.impl.wsdl.WsdlProject.getInterfaceByTechnicalId(WsdlProject.java:675) at com.eviware.soapui.impl.wsdl.actions.iface.CloneInterfaceAction.perform(CloneInterfaceAction.java:73) at com.eviware.soapui.impl.wsdl.actions.iface.CloneInterfaceAction.perform(CloneInterfaceAction.java:37) at com.eviware.soapui.support.action.swing.SwingActionDelegate.actionPerformed(SwingActionDelegate.java:93) at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972) at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2313) at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405) at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262) at java.desktop/javax.swing.AbstractButton.doClick(AbstractButton.java:374) at java.desktop/javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1028) at java.desktop/javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1072) at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297) at java.desktop/java.awt.Component.processMouseEvent(Component.java:6626) at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3389) at java.desktop/java.awt.Component.processEvent(Component.java:6391) at java.desktop/java.awt.Container.processEvent(Container.java:2266) at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5001) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2324) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833) at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4948) at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4575) at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4516) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2310) at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2780) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:775) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:747) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:744) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) Anybody has any idea, how to make this work? Thanks in advance
Shared workspace
Hi, I have a couple-three dozen Projects, stored on a Google Drive, that i want to share with a couple co-workers, such that we are all working off the same song sheet. I have shared the google drive folder where they all reside, with them, but is there a way to allow them to import all the Projects into their SoapUI in one swell foop? Has seen something about shared Workspace, but can't find anything about how to accomplish that. Can anyone suggest?
Help needed with importing an API via a URL that requires a certificate for authentication.
I am trying to connect to a vendor's API (SOAP). I have a project set up and I'm trying to import their APIs. We use a certificate to connect to the site. When I go to Import API definition, it erros out saying "Received fatal alert: certificate_required" How do I use the certificate file I have in ReadyAPI? Thanks, BFasanoProject WSDL replaced from another project
I have SoapUI v5.8.0 and two projects loaded. I noticed that if I open the Interface Viewer for first project, then the WSDL for the second project gets overwritten by the WSDL of the first project. In steps: - close SoapUI - open SoapUI - in the project list on the left (the Navigator), expand the first project and double click the first (and only) interface (the icon with two green arrows, pointing left and right) - the Interface Viewer appears with correct data, including the third tab named "WSDL Content", which shows the correct WSDL - now expand the second project and double click the first (and only) interface there - the Interface Viewer appears with correct data in the first tab (named "Overview"), but the third tab named "WSDL Content", shows the WSDL from the first project! Most things work, but if a TestCase in second project has a "Schema Compliance" assertion, it will fail, as the schema in the wrong WSDL is used and it does not match the actual test case result for a web service response. It is similar, if I first open the Interface Viewer for the second project, ie: - close SoapUI - open SoapUI - expand the second project and double click the interface - the Interface Viewer appears with correct data, including the third tab named "WSDL Content", which shows the correct WSDL - now expand the first project and double click the interface there - the Interface Viewer appears with correct data in the first tab (named "Overview"), but the third tab named "WSDL Content", shows the WSDL from the second project! After exiting SoapUI, the wrong WSDL is not saved. Also, if I don't open the Interface Viewer after starting SoapUI but just run the test suites, a similar thing happens: if I first run the test suites from first project, and then the tests from second project, the second project tests will fail with "Schema Compliance" assertions, as again, the second WSDL is "overwritten" with the first. The problem appears also when running testcases from java (using class com.eviware.soapui.SoapUI from soapui.jar): if first project test suites are run and then second project test suites, the second project tests will have an assertion error as they will compare to the wrong WSDL schema (the one from the first project). Important detail: for both projects the WSDL URL (as shown in the first tab of Interface Viewer) is same. This is because both the projects (the servers, not the SoapUI projects) were developed, well on my PC and they were created at different times, when running in my IDE. So both URLs are like: https://localhost:8443/foo/bar?wsdl I guess this may be related to the problem and will try a workaround by editing the SoapUI project XML file to make the URLs different. Unless a better approach is suggested...
