The BPELWS 1.1 specification mandates that when an assign is made, the “to” node must evaluate to exactly one node. If it evaluates to zero nodes, a bpws:selectionFailure must be thrown. This can become quite inconvenient as you have to pre-populate your XML fields to empty elements before assigning to them.

Let’s see it in practice.

Imagine you have the following XSD defining your input (process element) and output (processResponse).

And you have a BPEL service capable of returning the rest of the person’s info based on the informed ID. Your BPEL process should look like the following:

In the enrich assign we assign hard coded values to the name and age elements (it’s just a test...). We enrich the received person and copy it to the output as shown bellow:

The following SOAP request is made to the BPEL process:

You should be willing to receive a person as response containing name and age, however, you should receive an error similar to the one bellow:

faultName: {{http://schemas.xmlsoap.org/ws/2003/03/business-process/}selectionFailure} messageType: {{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage} parts: {{ summary=<summary>XPath query string returns zero node. The assign activity of the to node query is returning zero node. Either the to node data or the xpath query in the to node was invalid. According to BPEL4WS spec 1.1 section 14.3, verify the to node value at line number 76 in the BPEL source. </summary>}


The reason for such error is that the xpath /client:process/client:person/client:name did not evaluate to a single node but to zero.

One option would be to create the node empty with a “XML fragment” before assigning to it but it can become quite tedious. A better option is to use the Oracle extension property bpelx:insertMissingToData. To use such property, right click the copy line and select the insertMissingToData from the menu as shown bellow:

Do the same for the age assign and click Apply. Your assign should look like the one bellow:

Now, the BPEL process run should be successful, showing the bpelx:insertMissingToData helped a long way!

In this post I aim to show you how to write to files from a soapUI test case. This is really interesting when you have to change properties so that you can automate your tests and get free from manual file changes.

This was made easy by the possibility of running Groovy scripts as a test step and can help you to configure a parameter file or a properties file before running some piece of test.

So, to see this in practice, create a new soapUI Workspace and a new empty Project inside it. Add a new Test Suite to the project:

And add a new Test Case to the Test Suite:

Add a new Groovy Script step to the test case:

Inside the Groovy Script Test Step, enter the following source code:


File file = new File("/tmp/myConfig.properties")
file.delete()
file << ("PROPERTY1=123")
file << ("\r\n")
file << ("PROPERTY2=456")

This piece of code will:

• First open file at “/tmp” called myConfig.properties
• Delete it (if it exists)
• Then we write 2 key/value properties to the file, breaking the line between both of them.

The source code should look like the following image:

Now, run the script and you should see an information alert showing it was successful. Go to the file system and open the /tmp/myConfig.properties file. You should see it was generated as expected like shown in the image bellow:

As you may have noticed, this was pretty easy and this possibility enables you to change properties so that your tests can avoid human intervention to change property and other kinds of files.

The java.util.concurrent.Semaphore class is a counting semaphore useful to implement throttling over a shared resource.

The code bellow shows how to force only 5 threads to run concurrently even when we have 10 threads running.

package semaphore.tests;

import java.util.Date;
import java.util.concurrent.Semaphore;

public class SemaphoreTests {

  public static void main(String[] args) {
    Semaphore semaphore = new Semaphore(5);

    for (int i = 0; i < 10; i++) {
      new Worker(semaphore).start();
    }
  }
}

class Worker extends Thread {
  private Semaphore semaphore;

  public Worker(Semaphore semaphore) {
    this.semaphore = semaphore;
  }

  @Override
  public void run() {

    while (true) {
      try {
        semaphore.acquire();

        String msg = Thread.currentThread().getName() + " - running at: "
            + new Date();

        System.out.println(msg);

        Thread.sleep(10000);

      } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        break;
      } finally {
        semaphore.release();
      }
    }
  }
}

When running such code we see the following:

Thread-3 - running at: Thu Oct 20 23:38:48 GMT-03:00 2011
Thread-1 - running at: Thu Oct 20 23:38:48 GMT-03:00 2011
Thread-0 - running at: Thu Oct 20 23:38:48 GMT-03:00 2011
Thread-5 - running at: Thu Oct 20 23:38:48 GMT-03:00 2011
Thread-4 - running at: Thu Oct 20 23:38:48 GMT-03:00 2011

Thread-1 - running at: Thu Oct 20 23:38:58 GMT-03:00 2011
Thread-5 - running at: Thu Oct 20 23:38:58 GMT-03:00 2011
Thread-0 - running at: Thu Oct 20 23:38:58 GMT-03:00 2011
Thread-4 - running at: Thu Oct 20 23:38:58 GMT-03:00 2011
Thread-7 - running at: Thu Oct 20 23:38:58 GMT-03:00 2011

Thread-2 - running at: Thu Oct 20 23:39:08 GMT-03:00 2011
Thread-6 - running at: Thu Oct 20 23:39:08 GMT-03:00 2011
Thread-4 - running at: Thu Oct 20 23:39:08 GMT-03:00 2011
Thread-0 - running at: Thu Oct 20 23:39:08 GMT-03:00 2011
Thread-7 - running at: Thu Oct 20 23:39:08 GMT-03:00 2011

Thread-6 - running at: Thu Oct 20 23:39:18 GMT-03:00 2011
Thread-2 - running at: Thu Oct 20 23:39:18 GMT-03:00 2011
Thread-4 - running at: Thu Oct 20 23:39:18 GMT-03:00 2011
Thread-9 - running at: Thu Oct 20 23:39:18 GMT-03:00 2011
Thread-7 - running at: Thu Oct 20 23:39:18 GMT-03:00 2011

Notice that five threads run concurrently, sleep for five seconds and then another five threads run concurrently again and sleep for five seconds more and so on...

If you change the number of the Semaphore's permits to, for example, two permits, you should see only two threads running concurrently, sleeping for five seconds, then two more running and so on, proving that the Semaphore is controlling the throttling.

To change the number of permits, simply change the number that the Semaphore receives in its constructor: Semaphore semaphore = new Semaphore(2); and you should see:

Thread-2 - running at: Thu Oct 20 23:54:17 GMT-03:00 2011
Thread-3 - running at: Thu Oct 20 23:54:17 GMT-03:00 2011

Thread-2 - running at: Thu Oct 20 23:54:27 GMT-03:00 2011
Thread-0 - running at: Thu Oct 20 23:54:27 GMT-03:00 2011

Thread-2 - running at: Thu Oct 20 23:54:37 GMT-03:00 2011
Thread-4 - running at: Thu Oct 20 23:54:37 GMT-03:00 2011

Thread-2 - running at: Thu Oct 20 23:54:47 GMT-03:00 2011
Thread-7 - running at: Thu Oct 20 23:54:47 GMT-03:00 2011

Thread-2 - running at: Thu Oct 20 23:54:57 GMT-03:00 2011
Thread-7 - running at: Thu Oct 20 23:54:57 GMT-03:00 2011

We’ve seen how to implement a throttling mechanism using the Semaphore Java class. On the next post I’ll show how the Semaphore class can be used to control access to a pool of resources.

Did you know that the java.util.concurrency.ConcurrentMap provides some very useful methods beyond the ones provided by the traditional java.util.Map interface?

The java.util.concurrency.ConcurrentMap is implemented by java.util.concurrency.ConcurrentHashMap class which provides extreme scalability when used in a multi-threaded fashion, while still providing thread safety.

java.util.concurrency.ConcurrentMap interface provides four additional methods to the java.util.Map interface that are executed atomically without additional external synchronization needs:

1. putIfAbsent(key, value): which puts an item if the key is not already in the map, associated with a value.
2. remove(key, value): which removes an entry if the key maps to the given value.
3. replace(key, value): which replaces an entry if the key maps to some value already in the map.
4. replace(key, oldValue, newValue): which replaces an entry if the key maps to the oldValue, replacing it by newValue.

The interesting thing is that all these operations are performed atomically, what would not be possible to be externally implemented with ConcurrentHashMap as it uses a variable number of locks to improve scalability, with 16 locks by default and the lock guarding each entry may vary.

Bellow, we see the putIfAbsent method at work:

package collections;

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;

public class ConcurrentMapTest {

  private ConcurrentMap<String, String> map = new ConcurrentHashMap<String, String>();

  public static void main(String[] args) {
    new ConcurrentMapTest().test();
  }

  private void test() {
    map.put("key 1", "value 1");
    String value = map.putIfAbsent("key 1", "value 2");
    System.out.println(map);
    System.out.println(value);

    value = map.putIfAbsent("key 2", "value 2");
    System.out.println(map);
    System.out.println(value);
  }
}

Describing what is done, we first add the value "value 1" with key "key 1". Then we use putIfAbsent to put value "value 2" associated with key "key 1". As key "key 1" is not absent in the map, it returns the value already in the map and does not alter its contents. So, when printing the map, what is printed is:
{key 1=value 1} and the value returned prints "value 1".

The other piece of code does the same but uses a key that is absent in the map, what causes the entry to be added, so when printing the map it prints: {key 1=value 1, key 2=value 2} and the value returned is null as this key did not map to any value before.

The concurrent collections provide extreme scalability and, as we saw, it's not just that: they also provide nice new features as well. Take a look at the documentation and see what they can do for you. I also recommend buying the great book Java Concurrency in Practice. It's a great source of information. I bought it for my Kindle and I'm reading it for the second time. It's such a must have for any Java programmer.

After some time, I'm writing again. Hope I do not stay so long without posting again.

The ThreadLocal class allow you to set values that are accessible from the thread that stored such value. Using a thread local you can set the value and as long as you are in the same thread and have access to the thread local instance you can retrieve such value. Value is retrievable only from that thread and can be a good option to confine values to the thread which can be accessible from any method without having to be passed as a parameter.

To illustrate this behavior, we can see the following piece of code:

package threadLocal;

public class ThreadLocalTest {

  public static final ThreadLocal<String> THREAD_LOCAL = new ThreadLocal<String>();

  public static void main(String[] args) {

    THREAD_LOCAL.set("Any value...");

    MyClass obj = new MyClass();
    obj.execute();

  }
}

package threadLocal;

public class MyClass {

  public void execute() {
    String value = ThreadLocalTest.THREAD_LOCAL.get();
    System.out.println(value);
  }
}

In the code shown, the class ThreadLocalTest has a static property which is a thread local instance called THREAD_LOCAL. This static property is capable of maintaining values associated to the thread. When MyClass.execute() method is invoked it prints the value put by the main method even tough it had no parameter and the value was put by the main method. As long as they are in the same thread, it prints "Any value...".

If we change the code to something like we see bellow (omitting MyClass already shown):

package threadLocal;

public class ThreadLocalTest {

  public static final ThreadLocal<String> THREAD_LOCAL = new ThreadLocal<String>();

  public static void main(String[] args) {

    THREAD_LOCAL.set("Any value...");

    Thread otherThread = new Thread() {
      @Override
      public void run() {
        MyClass obj = new MyClass();
        obj.execute();
      }
    };

    otherThread.start();
  }
}

Now the execution prints null. This is because the value was put by the Main thread (yes, the main runs in its own thread) and we try to read it from a different one, represented by the otherThread object we created.

A nice thing beyond simple thread locals, that we have just shown, is that you can use the InheritableThreadLocal class. This class allow a thread and any threads started by it (and so on down the chain) to have access to the values put by threads higher up in the chain.

Let's see an example. Change the class ThreadLocalTest to something like what is shown bellow:

package threadLocal;

public class ThreadLocalTest {

  public static final InheritableThreadLocal<String> THREAD_LOCAL = new InheritableThreadLocal<String>();

  public static void main(String[] args) {

    THREAD_LOCAL.set("Any value...");

    Thread otherThread = new Thread() {
      @Override
      public void run() {
        MyClass obj = new MyClass();
        obj.execute();
      }
    };

    otherThread.start();
  }
}

Now, running this test prints Any value... again. This is due to the fact that the otherThread is started by the main thread, so it inherits the thread local attributes associated with the starter thread.

ThreadLocal and the InheritableThreadLocal are great features. Just take some precautions like guaranteeing that you remove the values associated with the threads via ThreadLocal.remove()method, specially in environments where the threads are pooled and reused.