Rupert Anderson's Blog

Mainly SoapUI, API, Open Source stuff and Elite Dangerous!

Replace Request In REST TestSteps SoapUI Plugin

Say you have the following scenario:

  1. A SoapUI REST Project defining a Service / Resource / Method / Request
  2. Have generated lots of REST Request TestSteps from it
  3. Then later you need to update the request content in the service definition
  4. And need all related TestSteps to also have their request content updated across all your TestSuites and TestCases  in the project?

Then you could manually update them, maybe write a script or even edit the project definition XML… or you could try this new SoapUI Plugin!

What It Does

  • Adds a new menu item under the REST request menu
  • When clicked this finds all TestSteps that were generated from the REST request
  • Replaces the found TestSteps request content with the content from the REST request
  • Only the request content for matching TestSteps is replaced, no other objects are changed


Here’s an example:

1. Consider the following small sample REST project:

  • There are 4 requests under resource1, lets pick Request 4.
  • Request 4 has two related REST Test Request TestSteps, both called Method3 – Request 4, one under TestCase 1 and the other under TestCase 2.
  • Then we edit the request content for Request 4.

2.Then to replace the request content in the 2 related TestSteps with the Request 4 request content:

  • Right-click on Request 4
  • Select the new menu item Replace Request In All TestStep(s)

3. Then you should see the the following message:

At this point:

  • The 2 Request 4 related TestSteps should have their request content replaced with Request 4s
  • No other TestSteps should be affected.

4. Alternatively, if you try this on a request with no related TestSteps (like Request 2), then you should see the message:

At this point nothing will be changed.


  • Please refer to the build and deployment steps on the GitHub project page
  • The first time you run the build, lots of SoapUI dependencies will be automatically downloaded and tests run, this might take a couple of minutes.
  • I tested the custom action against SoapUI 5.3.0, but it should work on other versions.

Development Approach

The approach I am going to take is:

  • Phase 1 (Done!) : First develop and trial the functionality as a SoapUI custom Action extension – this has allowed me to focus on the getting the core functionality ready for evaluation with the minimum focus on packaging.
  • Phase 2 (Future Option) : Repackage the functionality as a SoapUI Plugin jar as a slightly neater option.
  • Phase 3 (Future Option) : If the functionality seems popular and useful, I could make a pull request integrate the action code directly code into the SoapUI GitHub project as standard functionality.


In terms of limitations / further thoughts:

  • At this stage this functionality should really be referred to as a SoapUI custom Action, rather than a plugin – I decided to call it a plugin because I may soon provide a way to repackage it as one (Phase 2).
  • Currently only the request content gets replaced, not changes to the the parameters or media type – if this would be useful it could be added?
  • I haven’t done any performance tests e.g. replaced 100 TestSteps, although I can – please let me know if you see any problems.

I’ve linked to this blog article from the SoapUI O/S Feature Request. Please let me know if there are any questions / issues / suggestions that you have either here or on the feature request. Thanks!

SoapUI Google Analytics NullPointerException On Ubuntu


This is just a quick post to consolidate my findings when investigating why a Null Pointer Exception occurs in SoapUI when running on Ubuntu. The error occurs in the analytics code when it tries to obtain the machine’s MAC address. For now, I have hopefully found a quick work around explained below.

I tested this when running SoapUI 5.2.1 (built & run from source code) on a clean install of Ubuntu 14.04.4, Java 1.7u79 and running on VirtualBox.

Problem Description

When starting you may see:


Aside from, a similar error can also be seen in when using different areas of functionality.

Looking at either of those classes where the NPE occurs we can see route cause is the same piece of code:

NetworkInterface network = NetworkInterface.getByInetAddress(InetAddress.getLocalHost());
byte mac[] = network.getHardwareAddress();
MessageDigest hasher = MessageDigest.getInstance("SHA-1");
return createHexBinary(hasher.digest(mac));

You can probably see that network is coming back as null.


To understand why, and work around the problem, try running a snippet of the same code with logging added e.g. something like:



public class Main {

   public static void main(String[] args) {

      try {
         NetworkInterface network = NetworkInterface.getByInetAddress(InetAddress.getLocalHost());
         System.out.println("Machine Name="+ InetAddress.getLocalHost());
         System.out.println("Network Interface="+network);
         byte mac[] = network.getHardwareAddress();
         System.out.println("Mac Address="+mac);
         MessageDigest hasher = MessageDigest.getInstance("SHA-1");
         System.out.println("Hashed Mac"+hasher.digest(mac));
      catch(Exception e){
         System.out.println("Error generating Analytics session ID - returning empty String"+ e);

Depending on how your hosts file / network settings are, you may see something like:

Machine Name=ubuntutest-VirtualBox/
Network Interface=null
Error generating Analytics session ID - returning empty Stringjava.lang.NullPointerException

The Machine Name will vary on your machine, but the Network Interface can be seen as null and a NullPointerException is caught. The problem seems to be that NetworkInterface.getByInetAddress cannot match the Machine Name to any of the Network Interface values. Running ifconfg shows that there is indeed no match available:

ubuntutest@ubuntutest-VirtualBox:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 07:07:27:79:d2:07
inet addr: Bcast: Mask:
inet6 addr: fe80::a00:27ff:fe79:d101/64 Scope:Link
RX packets:21 errors:0 dropped:0 overruns:0 frame:0
TX packets:73 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3086 (3.0 KB) TX bytes:10810 (10.8 KB)

lo Link encap:Local Loopback
inet addr: Mask:
inet6 addr: ::1/128 Scope:Host
RX packets:46 errors:0 dropped:0 overruns:0 frame:0
TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3559 (3.5 KB) TX bytes:3559 (3.5 KB)


So without fixing the code, one quick solution is to change the /etc/hosts entry for your machine name to use the same IP address as eth0. So in my case, I did something like:

sudo nano /etc/hosts

And added:      ubuntutest-VirtualBox

Running the above snippet should then show the Network Interface correctly matched and the Mac Address found e.g.

Machine Name=ubuntutest-VirtualBox/
Network Interface=name:eth0 (eth0)
Mac Address=[B@520b368f
Hashed Mac[B@4a5e88f7

Note – adding a host entry pointing to lo ( solves the first problem of matching the Network Interface, but then fails when the code tries to obtain the MAC address with network.getHardwareAddress() – unlike eth0, the interface lo doesn’t have one!

Starting up SoapUI should now occur without the Analytics NPE.

Code Fix

Aside from having / changing your network settings to help the code work, it would probably be better to fix the code in SoapUI to iterate over the possible Network Interfaces until it finds one with a MAC address. I’ll maybe take more of a look at this later.


There are probably more or even better options for solving this problem, but I just wanted to get some options down in response to various SoapUI Community posts featuring this error for users running on Ubuntu. Hopefully this will help somewhat, please come in with any suggestions / corrections / comments!



R1-Developing and using custom Groovy libraries In SoapUI


So maybe you’ve built up some useful Groovy code for over time that you use again and again, spread across your projects, but would rather manage it from one place? If so, this recipe shows how you can create and import them via jar files so that you can reuse them from SoapUI objects like Groovy TestSteps, Setup/Teardown Scripts and Script Assertions.

Why bother?

  • This way of packaging your Java/Groovy code promotes reuse and can ease the maintainability of your commonly used test code.
  • It is possible to use these libraries to override existing SoapUI code/functionality i.e. create patches.
  • Whilst various recipes in the SoapUI Cookbook show how to use prebuilt Java/Groovy libraries, I felt this was a valid recipe and building block in its own right.

TIP: Quick Start – People who already have a suitable Java/Groovy library and just want to know how to use it in SoapUI, can jump in at step #6


This recipe uses Groovy and Gradle (v2.12) to compile and package the example Groovy class as a jar file. If you haven’t got Gradle, please refer to and

For mac/linux I used SDKMAN! ( e.g.

sdk install gradle
sdk install groovy (This is optional, useful if you want to run some Groovy without SoapUI)


1.Create the following directory structure


2.Get some Groovy code

For this example, I have knocked together a simple script to generate sequential ids. It may be of little practical use, but I wanted something with a simple public static method to call. Since the method is static, there will be no need to instantiate the class before calling it in step #8.

package custom 

import java.util.concurrent.atomic.AtomicLong 

public class SequentialIdGenerator { 
   public static final long counterSeed = 1000 
   public static final String prefix = "id"
   private static AtomicLong counter = new AtomicLong(counterSeed) 
   public static String nextId() { 
     return prefix + counter.incrementAndGet() 
  • create the above script as a text file called SequentialIdGenerator.groovy
  • copy it to soapuilib/src/main/groovy/custom

3.Create Gradle build script

For this part, there are plenty of options to build the code and package it, such as Maven, Ant or just running the right shell commands! The following minimal Gradle script allows us to compile and package the code as a jar in one easy statement.

apply plugin: 'groovy'

version = '1.0'

jar {
   classifier = 'library'
   manifest {
      attributes 'Implementation-Title': 'SoapUI Sample Groovy Library', 'Implementation-Version': version

repositories {

dependencies {
   compile 'org.codehaus.groovy:groovy:2.1.7' //Matches Groovy in SoapUI 5.2.1

  • Create the above Gradle script as soapuilib/build.gradle
INFO: Groovy Version – (At time of writing) The current version of Groovy is v2.4.6, but SoapUI 5.2.1 ships with Groovy 2.1.7. If you try to compile with a Groovy version 2.3+ and use it with SoapUI, you will see an error popup and log message in like ‘org/codehaus/groovy/runtime/typehandling/ShortTypeHandling‘ – see for more details and options. Basically, you can still use the latest Groovy version, but will need to include an additional groovy-backports-compat23 dependency!

5.Compile it & Create jar file

Now we’re ready to use the Gradle script to compile the sample script from step #2 and package it as a jar file.

  • Open a shell/command prompt at soapuilib/
  • gradle clean build jar

You should then see output like:

tests-MacBook-Pro:soapuilib test$ gradle clean build jar
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:compileTestJava UP-TO-DATE
:compileTestGroovy UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE


Total time: 5.499 secs

This build could be faster, please consider using the Gradle Daemon:

and our new library jar file created under the directory:


6.Add jar file to SoapUI

To make our new Groovy library jar available for use in SoapUI, it should be added in SoapUI Home under the following external library directory:

SoapUI ext Directory

Or the Windows equivalent e.g. C:\Program Files\SmartBear\SoapUI-5.2.1\bin\ext

7.Verify jar file is imported

When SoapUI is restarted, you should see the following log entry indicating that the jar file has been successfully added to the SoapUI classpath:

SoapUI ext Lib Loaded
8.Call the code

Our SequentialIdGenerator has a public static method nextId() that we can call, so to do this we can either import the class (Example 1)  or just prefix the class with its package (Example 2). See below:

  • Example 1 – Call from Groovy TestStep:
import custom.* SequentialIdGenerator.nextId()

Gives output like:

Thu May 12 16:49:20 BST 2016:INFO:id1001

  • Example 2 – Call from Property Expansion:

${= custom.SequentialIdGenerator.nextId()}


This section may evolve over time e.g. include details of further use-cases and examples. Anything you’d like to see, please ask!


No links yet.