Upgrade-safe inclusion of version-dependent JavaScript libraries in Oracle APEX


In one of our Oracle APEX 4.2 projects we wanted to use the famous jQuery UI autocomplete feature. By default, APEX 4.2 applications contain a subset of jQuery UI (see Oracle APEX 4.2 Documentation for more details). It is a pity autocomplete functionality is not part of that subset. Fortunately, the APEX server is shipped with the necessary libraries. That makes it easy to include them. When looking at the file structure of our APEX server, you can see that there are multiple versions of jQuery UI.

Each of these version folders contains a corresponding version of the autocomplete feature.

So, what is the correct version to include?

Using a JavaScript console it is quiete easy to determine the jQuery UI version which is automatically included by APEX. Just type


into your console’s CLI and have a look at the output.

Recognizing our jQuery UI version is 1.8.22 one way to include the appropriate version of our jQuery UI autocomplete feature would be to insert the following code into our page header.

<script type="text/javascript" src="#IMAGE_PREFIX#libraries/jquery-ui/1.8.22/ui/minified/jquery.ui.autocomplete.min.js"> </script>

But there is one serious disadvantage using this pragmatic approach. When you upgrade your APEX server in the future your APEX application might break. Why? Because the core jQuery UI libraries published by the APEX server could have another version. So our manually loaded autocomplete feature might not be compatible with this newer autoloaded jQuery UI version.

But don’t panic, there are solutions to keep the libraries in sync. I will explain three possible solutions using the following simple sample page. It contains a region called “jQuery AutoComplete Region” with one page item “P2_AUTOCOMPLETE_ITEM”.

When running the page without the autocomplete feature we are able to type some text into P2_AUTOCOMPLETE_ITEM. The input field works as designed, but this beavior is not so much impressive.

What we want to achieve is that P2_AUTOCOMPLETE_ITEM provides a list of suggestions using jQuery UIs autocomplete feature.

Solution 1 – Extend jQuery UI version included by default

This solution is simple but powerful. Whereas jQuery and a subset of jQuery UI is loaded by default, our task is to manually load the corresponding version of jQuery UI’s autocomplete module.The only thing we have to do is to put the following Immediately-Invoked Function Expression (IIFE) into the page header

<script type="text/javascript">
(function($, window, document, undefined) {
  function assignAutocompletion() {
		var availableTags = [
		  "ActionScript", "AppleScript", "Asp", 
		  "C", "C++", "Clojure", "COBOL", "ColdFusion", 
		  "Java", "JavaScript", 
		  "Perl", "PHP", "Python", 
		  "Scala",  "Scheme"];

		  source: availableTags

  $(document).ready(function() {
      if (!($.ui && $.ui.autocomplete)) {
		var imageDir = apex_img_dir || '/i/';
		var autocompleteSrc = imageDir + 'libraries/jquery-ui/' + $.trim($.ui.version) + '/ui/minified/jquery.ui.autocomplete.min.js';
		var globalJQuery = window.jQuery;
		window.jQuery = $;

		$.when($.getScript( autocompleteSrc )).then(function(){
		   $ = window.jQuery;
		   window.jQuery = globalJQuery;
      } else {
})(jQuery, window, document);	  

If the currently loaded jQuery object does not contain jQuery UI’s autocomplete module we will manually load it into the page. For that reason we build the URI of our jQuery UI autocomplete javascript file which is related to the currently loaded jQuery UI version (line 26). Please notice that we want to load the minified version of the file. The script itself is loaded using jQuery’s getScript() function (line 30). After jQuery UI autocomplete has been included we are able to bind the list of suggestions (line 4 pp.) to our input text field (line 18). To ensure the binding is invoked after the script has been loaded it is called by jQuery’s when()-function (line 30).

In order to test our code, we run our sample page once again. When typing the letter “j” into our input text field the expected autocomplete box appears!

Choosing this approach we ensure, that the versions of the autoloaded jQuery UI components and the manually loaded extension are in sync. This is upgrade-safe, as long as the jQuery UI API is not changed in future versions. If this is acceptable to you, solution 1 should be your choice.

Solution 2 – Include and use older jQuery/jQuery UI version

When implementing custom jQuery/jQuery UI based functionality in your APEX application, you are sure that the code works with the jQuery/jQuery UI versions you used to implement your code. As written in the introduction of this article the APEX server is shipped with multiple versions of jQuery. So, if the libraries we used to implement our custom behavior are delivered with future versions of APEX, it would be smart to use them.

When implementing custom jQuery based code, we have to determine the currently used jQuery-Version. Type


into your JavaScript console’s CLI and take the output. Let’s assume the output says your jQuery version is 1.7.1.

Keeping this information in mind, we have to edit the page template. Within the page template we can include jQuery 1.7.1 combined with jQueryUI 1.8.22 and assign it to a JavaScript variable jQuery1_7_1_UI1_8_22. In order to achieve this, we have to edit our page template. To open the edit view just double-click on the page template link in the application builder’s page view:

Insert the following code just before the #APEX_JAVASCRIPT# substitution string that appears in the “header” section. In APEX versions prior to 4.2 insert code before #HEAD# substitution string.

<script src="#IMAGE_PREFIX#libraries/jquery/1.7.1/jquery-1.7.1.min.js" type="text/javascript"></script>
<script type="text/javascript" src="#IMAGE_PREFIX#libraries/jquery-ui/1.8.22/ui/minified/jquery-ui-1.8.22.custom.min.js"> </script>
<script type="text/javascript" src="#IMAGE_PREFIX#libraries/jquery-ui/1.8.22/ui/minified/jquery.ui.autocomplete.min.js"> </script>

<script type="text/javascript">
    var jQuery1_7_1_UI1_8_22 = jQuery;
	jQuery = {};

This ensures, that jQuery version 1.7.1 is loaded (line 1). This jQuery version is extended by jQuery UI 1.8.22 (line 2), which itself is extended by jQuery UI autocomplete feature 1.8.22 (line 3). The whole setup is stored into JavaScript variable jQuery1_7_1_UI1_8_22 (line 6).

In order to use jQuery 1.7.1 instead of the APEX default jQuery version, we have to change the arguments (last line) of our Immediately-Invoked Function Expression (IIFE) in our page header from

})(jQuery, window, document);


})(jQuery1_7_1_UI1_8_22, window, document);

As a result code within the IIFE will use jQuery 1.7.1 instead of the jQuery version shipped with the APEX server. The rest of your APEX application will use the version shipped with APEX. The benefit you get using this solution is, that your code always runs against the jQuery version you used to develop the code. The disadvantage is that you have to trust in Oracle that future versions of APEX will be delivered with “your” jQuery/jQuery UI version.

Solution 3 – The best of 1 and 2

To avoid the disadvantages of solutions 1 and 2 it would be nice if the jQuery/jQuery UI versions you have used during development would only be used if they are available.

No problem!

Just perform all steps of solutions 1 and 2, but change the arguments of the IIFE call from

})(jQuery, window, document);


})((typeof jQuery1_7_1_UI1_8_22 !== "undefined" && jQuery1_7_1_UI1_8_22.ui) ? jQuery1_7_1_UI1_8_22 : jQuery, window, document);

This ensures that “your” jQuery-Version (1.7.1) is only passed into IIFE, if it has been loaded and extended by “your” jQuery UI version 1.8.22. Otherwise the default jQuery version delivered by APEX server will be used.

LOV to pick month within an interval of half-a-year around current date

In one of our famous APEX projects we had the requirement to select a month from a select list. The select list itself should contain all months half a year before and half a year after current date. Below you can see the select-statement of our LOV. Maybe it will be helpful for somebody out there.

 with dates as (
    select add_months(add_months(trunc(sysdate, 'MM'), -6), offset) first_day_of_month
    from (
      select level - 1 offset
      from dual
      connect by level <= 13
  select to_char(first_day_of_month, 'Month YYYY') display_value, to_char (first_day_of_month, 'YYYYMM') return_value 
  from dates

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 http://www.oracle.com/technetwork/developer-tools/adf/uishell-093084.html.

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 Launcher.java 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 “UIShellParameter.zip” 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
export _JAVA_OPTIONS="-Djava.io.tmpdir=$HOME/tmp $_JAVA_OPTIONS"
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.

How To Resolve Cinnamon Installation Issue

I recently tried to install Cinnamon as the primary desktop environment for my Linux Mint 12 system. The command

sudo aptitude install cinnamon-session

resulted in the following error message

Err http://packages.linuxmint.com/ lisa/main cinnamon amd64 1.1.2 404 Not Found
Get: 1 http://packages.linuxmint.com/ lisa/main cinnamon-session all 1.0.0 [1,634 B] Fetched 1,634 B in 0s (2,614 B/s)
E: Failed to fetch http://packages.linuxmint.com/pool/main/c/cinnamon/cinnamon_1.1.2_amd64.deb: 404 Not Found
E: Failed to fetch http://packages.linuxmint.com/pool/main/c/cinnamon/cinnamon_1.1.2_amd64.deb: 404 Not Found

To fix this issue and successfully install cinnamon execute the following command in a terminal window (CTRL + ALT + T):

sudo aptitude update && sudo aptitude install cinnamon-session

Please note: If you prefer apt-get over aptitude or aptitude is not installed on your system just replace all occurrences of aptitude with apt-get.

Hello world!

Welcome to my blog! My name is Hendrik Gossens and I work as an IT Consultant at MT AG, Germany. My focus is on Oracle technology, especially on Oracle ADF. Moreover, I am interested in Linux. Currently I am running a Linux Mint system with Cinnamon as its desktop environment.This blog will be a kind of private knowledge base containing information and howtos on Oracle ADF, Linux and other technologies I use in my daily life. Maybe those information are also interesting to someone out there. Human knowledge belongs to the world!

Blog about Oracle ADF, MAF and related technologies