Good news for Solaris x64 users: Oracle Service Bus 11g PS3 is now supported on this platform. But the prerequisite wls1034_generic.jar installer fails on some disk configurations with the following error:

Extracting 0%....................................................................................................100%
Insufficient disk space! The installer requires:
190MB for the BEA Home at /home/trivadis/Oracle/Middleware,
450MB for the product at /home/trivadis/Oracle/Middleware/utils/uninstall/WebLogic_Platform_10.3.4.0,
/home/trivadis/Oracle/Middleware/wlserver_10.3 and
1139MB temporary work space at /home/trivadis/tmp/bea2001687921370458260.tmp.
There is only 1MB available at /home/trivadis/Oracle/Middleware.


There is certainly more than 1MB available on the affected disk, in fact there are more than a 100 GB available! I did not really figure out what causes the space detection routine to fail, but I found a workaround to switch the available-space-check off:

Just create a file /home/bea/installoptions.bea (this is where the generated file beahomelist usually gets placed).

Put the following line into this file:

space.detection=false


Start the installer again and it will run like a breeze!

If you run into other problems and like to debug the installer, just start it with the following line:

java -d64 -Xmx1024m -Dcom.bea.plateng.common.util.logging.useJDKlogger=true -log=./wls.log -jar /home/trivadis/wls1034_generic.jar


To even see debug log entries in wls.log, put the following line at the bottom in your /lib/logging.properties file:

com.bea.plateng.level = FINEST


As is known, there is no explicit NULL in XQuery. There are empty sequences, and you can mark an element with the xsi:nil attribute to represent NULL: <elem xsi:nil="true"/>. But there is no NULL-equivalent for basic data types.

Nevertheless, I checked how OSB’s XQuery implementation behaves, if one tries to transfer null values. Here is the result:

First, we write three Java methods, taking a string parameter and returning null, an empty string and a whitespace-string.

package com.trivadis.osb.xpath;

public class NullInXQuery {

	public static String retNull(String arg) {
		System.out.println("retNull(): arg: '" + arg + "'");
		return null;
	}

	public static String retEmpty(String arg) {
		System.out.println("retEmpty(): arg: '" + arg + "'");
		return "";
	}

	public static String retSpace(String arg) {
		System.out.println("retSpace(): arg: '" + arg + "'");
		return " ";
	}
}

Add an entry for each method in the configuration XML:

<?xml version="1.0" encoding="UTF-8"?>
<xpf:xpathFunctions xmlns:xpf="http://www.bea.com/wli/sb/xpath/config">
    <xpf:category id="Testing Null behaviour Functions">
        <xpf:function>
            <xpf:name>retNull</xpf:name>
            <xpf:namespaceURI>http://trivadis.com/osb/nullinxquery</xpf:namespaceURI>
            <xpf:className>com.trivadis.osb.xpath.NullInXQuery</xpf:className>
            <xpf:method>java.lang.String retNull(java.lang.String)</xpf:method>
            <xpf:isDeterministic>true</xpf:isDeterministic>
            <xpf:scope>Pipeline</xpf:scope>
            <xpf:scope>SplitJoin</xpf:scope>
        </xpf:function>
        <xpf:function>
            <xpf:name>retEmpty</xpf:name>
            <xpf:namespaceURI>http://trivadis.com/osb/nullinxquery</xpf:namespaceURI>
            <xpf:className>com.trivadis.osb.xpath.NullInXQuery</xpf:className>
            <xpf:method>java.lang.String retEmpty(java.lang.String)</xpf:method>
            <xpf:isDeterministic>true</xpf:isDeterministic>
            <xpf:scope>Pipeline</xpf:scope>
            <xpf:scope>SplitJoin</xpf:scope>
        </xpf:function>
        <xpf:function>
            <xpf:name>retSpace</xpf:name>
            <xpf:namespaceURI>http://trivadis.com/osb/nullinxquery</xpf:namespaceURI>
            <xpf:className>com.trivadis.osb.xpath.NullInXQuery</xpf:className>
            <xpf:method>java.lang.String retSpace(java.lang.String)</xpf:method>
            <xpf:isDeterministic>true</xpf:isDeterministic>
            <xpf:scope>Pipeline</xpf:scope>
            <xpf:scope>SplitJoin</xpf:scope>
        </xpf:function>
	</xpf:category>
</xpf:xpathFunctions>

Finally call the functions within a ProxyService’s log action:

<x>
<null>{nulo9:retNull(<elem xsi:nil="true"/>)}</null>
<empty>{nulo9:retEmpty("")}</empty>
<space>{nulo9:retSpace(" ")}</space>
</x>

As you can see, we try to pass a nilled element to the Java method (hoping it will be converted to null). Further we pass an empty string and a string containing whitespace only.The methods themselves return null, an empty string and a whitespace-string.

After you execute the ProxyService, you will see the following in the stdout log file:

retNull(): arg: ''
retEmpty(): arg: ''
retSpace(): arg: ' '
<17.10.2010 22:58 Uhr MESZ> <Debug> <ALSB Logging> <BEA-000000> < [PipelinePairNode1, PipelinePairNode1_request, stage1, REQUEST] <x>
  <null/>
  <empty/>
  <space></space>
</x>>

So, there seems to be no way to pass null between Java and XQuery in either direction. null will always be converted into an empty string, the same applies to a nilled element.

For other basic data types, the situation seems to be somewhat inconsistent. For instance, if you try the same with a custom XPath function taking and returning java.lang.Integer, you will receive the following error if you call the custom XPath function with a <elem xsi:nil="true"/> parameter value:

weblogic.xml.query.exceptions.XQueryDynamicException: {err}XP0021: "": can not cast to {http://www.w3.org/2001/XMLSchema}integer: error: decimal: Invalid decimal value: expected at least one digit

The same Java method returning a java.lang.Integer null leads to:

weblogic.xml.query.exceptions.XQueryTypeException: line 5, column 28: {err}XP0006: "0 ({http://www.w3.org/2001/XMLSchema}integer)": bad value for type {http://www.w3.org/2001/XMLSchema}int

For java.sql.Date, however, the situation looks similar at first. For a method taking and returning java.sql.Date, passing <elem xsi:nil="true"/> leads to:

weblogic.xml.query.exceptions.XQueryDynamicException: {err}XP0021: "": can not cast to {http://www.w3.org/2001/XMLSchema}date: error: date: Invalid date value: wrong type

But the same Java method returning a java.sql.Date null in contrast runs smoothly!

If somebody knows a practical and consistent way to pass null between Java and XQuery, you are welcome to add a comment!

But how do you install it in an existing environment without reinstalling OSB afterwards?

Simply unzipping the downloaded zip file into a new folder within the middleware home does not work. You won’t be able to create Oracle Service Bus Configuration projects. Or, if you open existing projects you will miss the ability to add Service Bus projects to Service Bus Configuration projects (Eclipse tries to move one folder physically into another instead).

In fact, there is not much to do to get it working:

1. Download OEPE 11.1.1.6

2. Unzip it into your middleware home. Mine is located at D:\Oracle\Middleware so I unzipped it into D:\Oracle\Middleware\oepe11_1_1_6_0

3. Create a file named oracle.osb.ide.link in the directory D:\Oracle\Middleware\oepe11_1_1_6_0\dropins\

4. Open the file in a text editor an insert the following line:
   path=D:/Oracle/Middleware/Oracle_OSB1
   The path points to your OSB installation directory. Notice the forward slashes.

5. Open the file D:\Oracle\Middleware\oepe11_1_1_6_0\eclipse.ini in a text editor

6. Modify the memory arguments according to this:
   -Xms256m
   -Xmx768m

7. Add the following lines to the end of the file (adjust paths according to your environment):
   -Dweblogic.home=D:\Oracle\Middleware\home_11gPS2\wlserver_10.3
   -Dharvester.home=D:\Oracle\Middleware\home_11gPS2\Oracle_OSB1\harvester
   -Dosb.home=D:\Oracle\Middleware\home_11gPS2\Oracle_OSB1
   -Dosgi.bundlefile.limit=500
   -Dosgi.nl=en_US

That’s it. Start eclipse.exe. Some more tips probably ease your life:

• Create a fresh Eclipse workspace.

• This means all your runtime environments, servers and the like are gone. It’s vital to create the new ones with exactly the same names as they have got in the old workspace. Otherwise your OSB projects point to not existing resources and you will have a hard time getting everything back to work.

• Import all the OSB projects into the new workspace.

• If you have trouble with your existing Oracle Service Bus Configuration project, simply drop the old and create a new one. It is not much work to configure the target server and to add all the OSB projects to the OSB Configuration project via drag&drop.