Providing Input Parameters for Taskflows in UI Shell

When trying out to build your own UI Shell based application you possibly have used the pre-implemented source code for your launcherBean that can be found at

This code works well, but if you want to pass parameters into a taskflow the Launcher class does not provide any interface. The solution is simple but powerful.

When analyzing UI Shell’s TabContext class you will find two appearances of a method called addTab:

public void addTab(String localizedName, String taskflowId);
public void addTab(String localizedName, String taskflowId, Map<String, Object> parameters);

As you can see in the signature of the second addTab-method, UI Shell provides the possibility to pass a Map<String, Object> that holds parameters for our task flow. Keeping that knowledge in mind we are able to modify the Launcher class provided by OTN in two steps:

1. Overload method _launchActivity

In order to overload the pre-implemented _launchActivity method edit and insert the following code snippet:

private void _launchActivity(String title, String taskflowId, boolean newTab,
                               Map parametersMap) {
    try {
      if (newTab) {
        TabContext.getCurrentInstance().addTab(title, taskflowId,
      } else {
        TabContext.getCurrentInstance().addOrSelectTab(title, taskflowId,
    } catch (TabContext.TabOverflowException toe) {

2. Simplify old _launchActivity method

For consistency reasons we should modify the “original” _launchActivity method in the following way:

private void _launchActivity(String title, String taskflowId,
                               boolean newTab) {
    this._launchActivity(title, taskflowId, newTab, null);

An example of passing a parameter into a taskflow is shown below. Create a button within your navigation area. Define the following code snippet as an action listener method of that button (insert code into your launcher class).

public void launchWithParameterTaskFlow(ActionEvent actionEvent) {
    Map map = new HashMap();
    map.put("inParameter", "Hello World!");

                    false, map);

So, what does this new method cause? When the button is clicked we generate a HashMap that contains the parameter inParameter with its value “Hello World!”. This map is used to pass the containing parameter into the taskflow via _launchActivity method.

Sample Taskflow

This paragraph describes how to build a sample taskflow. The taskflow itself contains a single view activity with a corresponding page fragment. To use the inParameter we want to pass, we have to define an input paramter in our taskflow. To do this open the taskflow and click somewhere, but not onto the view activity. The property inspector should show the task flow definition attributes now. Under section Parameters we can see the subsection Input Parameter Definitions. Click the green plus to add a new parameter. Name the parameter inParameter and define that its class is java.lang.String. The fields “value” and “required” should be empty. Have a look at the image below to see an overview of the desribed information in this paragraph. As you can see, the name of the task flow input parameter must match the key we passed in our parameters map via _launchActivity method.


As intended, we are able to use the input parameter within the taskflow by using the EL expression #{pageFlowScope.inParameter}.

Please note: I already posted this on ADF Juggernaut in march 2011.

Update: I have submitted a simple sample application regarding this topic to ADF EMG Samples repository. Search for “” or click here to download it!

JDeveloper Installation on Debian – “no space left on device” Issue

Hello world!

Yesterday I installed Linux Mint Debian Edition (LMDE) on my notebook. It seems to be a rock solid distribution, but as Clem announced in his blog post it has “some rough edges”. One rough edge I had been experiencing was an annoying “no space left on device” error when I tried to install Oracle JDeveloper on my brand new system. Believe it or not: The error cause is not a bug – it is a feature! This post is about fixing the installation issue caused by that feature. Although it talks about a JDeveloper installation the suggested ways can be a applied to other programs that cause the issue mentioned above.


As described in the previous paragraph I tried to install Oracle JDeveloper on my notebook:

java -jar jdevstudio11116install.jar

After a few seconds the following window was popping up:

Cause Analysis

The error description “no space left on device” was a little bit confusing to me, because I just installed LMDE on a 500 GiB hard disk and I could not imagine that LMDE would have occupied the whole disk space. When checking the free disk space with

df -k

I recognized the high usage of the /tmp partition (96%, line 6):

Filesystem 1K-blocks Used     Available  Use% Mounted on
rootfs     477387180 15714056 437778136    4% /
udev         4032380        0   4032380    0% /dev
tmpfs         807556      912    806644    1% /var/run
tmpfs           5120        0      5120    0% /var/run/lock
tmpfs        1615112  1541124     73988   96% /tmp
tmpfs        1615112       76   1615036    1% /var/run/shm

Newer debian (linux) systems allow to use RAM as a “directory” for writing / reading temporary data. This increases speed of programs that need space for temporary data. For the most use cases the size of such a RAM-based temporary partition is adequate. An insurgent program that needs a huge amount of temporary space is the Oracle JDeveloper installer. It looks up the system’s temp directory in order to extract round about 2 GiB of data to that directory. So the cause of the occuring “no space left on device” error was the huge amount of data the installer tried to write to my limited RAM-based /tmp partition.


There are (at least) three ways to solve the issue.

Solution 1 – Dynamically resize /tmp at runtime

Because /tmp is mounted as a tmpfs you can resize it dynamically at runtime. Just clear the content of /tmp and resize its space:

sudo rm -rf /tmp/*
sudo mount -o remount,size=2560m /tmp
java -jar jdevstudio11116install.jar

This is the recommended way, because it ensures a fast running installation process. For installing JDeveloper the size of 2560m (= 2.5 GiB) was adequate. Depending on your use case you might have to choose a higher value like 3g (= 3 GiB).

Solution 2 – Use custom directory instead of RAM for temporary data (java specific)

The JDeveloper installer is a java program. So it is possible to configure a custom temp directory via _JAVA_OPTIONS environment variable:

mkdir $HOME/tmp
java -jar jdevstudio11116install.jar

Runtime of this approach is a little bit slower than runtime of solution 1, but it works…

Solution 3 – Use disk space instead of RAM (system-wide and permanent => slows down programs that access /tmp)

Another solution is to prevent /tmp from being mounted as RAM based tmpfs. To achieve this perform the following two simple steps and you are done:

  • Edit /etc/default/rcS as superuser and replace RAMTMP=yes by RAMTMP=no
  • reboot

Works like solution 2, but is not java specific. In contrast to the first two solutions, it has a permanent effect. You should choose this option, if you are constantly experiencing the “no space left on device” error when running various programs.


Please note: A filled to overflowing /tmp partition is not the only matter that can cause a no “space left on device” error. If you are not able to identify a chock-full /tmp partition by using

df -k


df -i

to see, if you are running out of inodes. If you are able to identify a value near 100% follow the instructions on Ivan Kuznetsov’s blog.