ContributionsMost RecentMost LikesSolutionsNo OPTIONS HTTP methodToday I started testing a RESTful API which implements OPTIONS. And to my surprise SoapUI lacks OPTIONS method support when creating REST methods. Come on guys - this is a bad miss P.S. SoapUI 4.5.2SoapUI breaks method names when adding WADLHi, There is the following critical bug in SoapUI 4.0.1 Pro which greatly prevents the colaborative usage of SoapUI projects and Test suit importing. The bug manifests itself in the following: - Adding SoapUI-generated WADL file to a project will result in the method names being broken. If a method is named "Method 1" in the original project then in the project with the imported WADL the method will get a name in the form "Method 1 - Method 1" ("method:@id - doc:@title" from the WADL XML definition). If the the <doc> tag of the <method> definition in the WADL file is missing, then the name will be " - Method 1". Consequences: Importing a test suite in project with imported WADL will break the Test suite, because reource method names have changed. In teams where WADL files and Test suites are exchanged between members in the form of files then this leads to broken tests. To reproduce: 1. Create new project 2. Add REST Service 3. Add a resource 4. Add a method and name it "Method 1" 5. Create Test suite and a test case with step using "Method 1" 6. Export the SoapUI-generated WADL and the Test suite 7. Create new project 8. Add the generated WADL file from Step #6 9. BUG: Observe the method name being named as "Method 1 - Method 1" 10. In the second project import the test suite exported in Step #6 11. CONSEQUENCE: The test suite will not import properly because there is no "Method 1" Please, make SoapUI to construct method names when importing WADL only from the ID attribute of the METHOD tag in the WADL file.JSON parameters and POST request parameter handlingSoapUI is the best for simple POST requests, but totally misses the point when it comes to REST+JSON. Given the great way it handles parameters from resources down to the request level, it would be cool to: - Add possibility to be able to fetch parameter values in a POST request body from the resource/method parameters. I.e., use right click in POST request body -> Get Data -> All parameters (not only Project level custom properties) - Add JSON parameter style, which converts a |Key|Value| pair to "key":"value" for strings and "key":value for integers/boolean and is not eligible for query submission in the URL This way it will be possible to better handle JSON REST tests. Sample PLAIN parameters handling in POST REST request A sample work flow will be: 1. Create REST resource and define some PLAIN style parameters 2. Add a method 3. Create a POST request 4. In the POST request body shape up a JSON template and use the PLAIN parameters as data source from the REST resource. Here SoapUI would simply get the value from the PLAIN parameter and the user will need to shape up the JSON object tags and layout Given a REST Resource parameter: - named "parameterNameFormResourceOrMethod" with value "12345" of type PLAIN and the following POST request body: { "key": "${parameterNameFormResourceOrMethod}" } then SoapUI will produce the following POST request body: { "key": "12345" } Better approach to JSON POST requests 1. Create REST resource and define some JSON style parameters 2. Add a method 3. Create a POST request 4. Create the basic JSON request POST body and add the parameter name. SoapUI will create the proper key:value pair according to the JSON notation and parameter type. Given the following REST Resource parameters - Parameter named "paramName1" with value "someString" of style JSON with type String - Parameter named "paramName2" with value "12345" of style JSON with type Integer and the following POST request body: { ${paramName1}, ${paramName2}, } then SoapUI will produce the following POST request body: { "paramName1":"someString", "paramName2":12345 } Re: SoapUI Maven artifact with missing dependenciesOK, got a reply that this is to be fixedRe: SoapUITestCaseRunner not endingYes - the same situation occurs on another machine. The steps to reproduce is: 1. Get SoapUI zip version 4.0.1 2. Create Java project (in Eclipse) 3. Add "lib" jars from SoapUI archive and the main soapui-4.0.1.jar 4. Create a new class with public static void main() method. WARNING: using a static main method is extremely important. Using a test JUnit method will not do. 5. Create a new SoapUITestCaseRunner 6. Run the Java application 7. Observe the application not stopping import com.eviware.soapui.tools.SoapUITestCaseRunner; public class SoapUiTest { public static void main(String[] args) { new SoapUITestCaseRunner(); } } Debugging the code appears to be leaving two threads running: - Thread [Timer-0] (Running) - Thread [DestroyJavaVM] (Running) Obviously there is some Timer left behind.Re: Help grabbing contents of a specific nodeYou can do the following: //node2/name[text()="ABC"]/../guid Just put this in the XPath box for the Source of the property transfer. And don't forget to select the Source step and Property: ResponseRe: SoapUITestCaseRunner not endingSome info on my system: Windows 7 Pro x64 SoapUI 4.0.1 x32 All I do is copy the lib from SoapUI folder and write a Java class creating SoapUITestCaseRunner instance.SoapUITestCaseRunner not endingHi, I am trying to use SoapUI within Java. Interestingly, the following code sets the Java VM to run forever as if a thread refuses to die. public static void main(String[] args) { new SoapUITestCaseRunner(); } I have just imported the lib directory of my SoapUI 4.0.1 installation. Actually, the problem is that I start the tests from FitNesse. But after they run (another code is used, of course) FitNesse page stalls at "Running". I hunted down and reached to the conclusion that a simple SoapUITestCaseRunner object creation causes the JVM to run endlessly. Anyone has idea how come?SoapUI Maven artifact with missing dependenciesHi, I am using SoapUI Maven dependency to use SoapUITestCaseRunner into Java tests: <dependency> <groupId>eviware</groupId> <artifactId>soapui</artifactId> <version>4.0.1</version> </dependency> The problem is that this dependency definition will only make Maven download soapui-4.0.1.jar and no other dependencies. Thus, when attempting to create new SoapUITestCaseRunner(), then the following exception occurs: java.lang.ClassNotFoundException: org.apache.commons.cli.CommandLineParser at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) ... 2 more loadUI 1.5 does not start with Java 7Hi, I am on: - Windows 7 x64 - JDK/JRE 7 (x32 build b147) - loadUI 1.5 The problem is that loadUI refuses to start with this configuration. Java 6 loading screen shows, disappears then nothing happens. The moment I uninstall Java 7, loadUI starts again.