Developer Cloud Service with JDeveloper 12.2.1 available

I almost missed that Developer Cloud Service has been updated to 12.2.1. Great news as we now can use JDeveloper 12.2.1 to access the agile capabilities like

  • Interact with Tasks/Issues in JDeveloper
  • Leverage the Team view in JDeveloper (tasks, builds, and code repositories)
  • Connect to DevCS and its projects from inside JDeveloper
  • Create Agile boards and manage sprints in Developer Cloud Service
  • Associate code commits with specific tasks
  • Monitor team activity in the Team Dashboard
  • Handle Git transactions

For more information about how JDeveloper and the DCS are integrated watch this video ‘Agile development with Oracle JDeveloper and Oracle Developer Cloud Service’.

This was possible since last year. So, what’s new?

New is that the JCS is also available in 12.2.1 and that we can use the whole continuous integration scenario. For this we have to configure a 12.2.1 JCS instance which then can be used for deployment. When we select to create a new instance of a JCS we see the new wizard which allows us to select a WebLogic Server 12c in version 12.2.1

On the ‘Edition’ page we don’t find anything new so we skip it and go to the Details page where we specify the needed information for the service, database configuration, backup and the WebLogic user

After getting the confirmation page we create the new service and finally after a short time we see the new service

A look at the Enterprise Manager of the new service shows the new login page

and after logging in the new 12.2.1 Enterprise Manager

It look modern and fresh. However, this is not what this blog is about. I installed my ADF Version Web Service BlogAdfVersionWS to check which ADF version is running in this instance. Selection the modules we find the test point on the right side of the Web Service

After selecting the test point we select to run the ‘GetVersion’ service

and get

That’s right what we expect when running ADF 12.2.1!

Next time we see how to change the build and deployment part of the DCS to work with the JCS 12.2.1.

Fasten your seat belts: Flying the Oracle Development Cloud Service (3 – Take Off – ROTATE)

The last part of the series 3 – Take Off – V1 we finished when we could build hte application using ANT on the local machine. In this part we are going to try this on the Oracle Developer Cloud. Finally we should see how Continuous Integration and Continuous Delivery works in the cloud.

Alt NOTE
I created a fresh set of ANT build scripts named ‘buildlocal.xml’ and ‘buildlocal.properties’ from the project to demonstrate the process. The original ones name ‘build.xml’ and ‘build.properties’ are the final result which I didn’t want to revert. So when you create the ANT scripts yourself you can user the default names ‘build.xml’ and ‘build.properties’. When I talk about build files I now mean the ones named ‘buildlocal.*’.

Demo Build Files

Demo Build Files


For the same reason we create a new build job in the cloud names ADFTestBuild to show the steps to take. The final build job is named ADFCommunuityFrkExt.
Demo Build Job

Demo Build Job

We pushed the files local build files already to the remote repository. Let’s run the build on the could. First we log into the Oracle Developer Cloud as team member and switch to the build tab and create a new build job (ADFTestBuild)


Note that we use JDK 7 to build the project. The Oracle Developer Cloud offers JDK 6-8 to work with. As we use JDev 12.1.3 we use JDK 7
JDK's available

JDK’s available


In the Source Code Management section we select the repository and branch to use for this job. The advanced section can be left blank as it’s filled by the system when you save the job. There are more advanced option you can set but they are not part of this post. All we nach to remember

Alt NOTE
Builds are dependent on ONE branch

Alt NOTE
The Build Trigger defines that each minute the CI system checks the SCM if something has changed. If yes, it schedules to execute the build job.

When we are finished with the feature we have to change the build job or to create a new one which uses the master or default branch to build on. In our situation where we implement the CI we set the branch to the one we are working on named ‘feature-setup-build’.

After saving the new job we can start it by clicking on the ‘Run Now’ button


Hm, the build did not work as it did on the local machine. This is shown by the icon in the first column of the job history table. To find out what went wrong we look at the output of the build by clicking on the ‘console’ button in the last column of hte table
Build output

Build output


In the first marked section we see the build file ‘buildlocal.xml’ which was used and in the second marked section the error message. It looks liek the build job can’t find the task ‘OJDeployAntTask’. A look into the buildlocal.xml file at line 40 reveals

   <taskdef name="ojdeploy" classname="oracle.jdeveloper.deploy.ant.OJDeployAntTask" uri="oraclelib:OJDeployAntTask"
             classpath="${oracle.jdeveloper.ant.library}"/>

where line 40 is the classpath in the above listing. This means that the variable “${oracle.jdeveloper.ant.library}” is not found. A look into the Oracle Developer Cloud at Developing Oracle ADF Applications with Oracle Developer Cloud Service give the needed information. We have to alter the build files
1. add a line

<property environment="env"/>

to the build.xml file before loading the build.properties
2. change the build.properties file to use information from the now loaded environemnt
The second part is a bit confusing. From the link above we learn to set a variable as
oracle.home=${env.ORACLE_HOME}
which is misleading a bit. The problem is that the developer cloud offers two environments to the user. One for 11g and one for 12c. As we use the one for 12c we have to use a different setup which can be found in the docs too at a different location Using Hudson Environment Variables. The second link tells us to use
oracle.home=${env.ORACLE_HOME12C3}

Alt NOTE
Add property environment="env" to your build.xml to load the environment of the server
Alt NOTE
Add
oracle.home=${env.ORACLE_HOME_12C3}
oracle.commons=${env.MIDDLEWARE_HOME_12C3}/oracle_common
middleware.home=${env.MIDDLEWARE_HOME_12C3}
install.dir=${env.ORACLE_HOME_12C3}
to the build.properties file to make use of hte servers environment.

With this info we can make the needed changes. The resulting build.properties is

#Fri Jul 24 15:06:08 CEST 2015
#Change the next three properties to match your projects names
workspace.name=ADFCommunityFrkExt
workspace=${env.WORKSPACE}
project.viewcontroller.name=FrkExtModel
project.deploy.folder=deploy
oracle.jdeveloper.deploy.profile.name=adflibADFCommunityFrkExt
output.dir=classes

# Don't change anything below!
oracle.home=${env.ORACLE_HOME_12C3}
oracle.commons=${env.MIDDLEWARE_HOME_12C3}/oracle_common
middleware.home=${env.MIDDLEWARE_HOME_12C3}
install.dir=${env.ORACLE_HOME_12C3}

#Flags
javac.deprecation=off
javac.nowarn=off
java.debug=on

project.workspace.file=${workspace.name}.jws
oracle.jdeveloper.ant.library=${oracle.home}/jdev/lib/ant-jdeveloper.jar
oracle.jdeveloper.workspace.path=${workspace}/${workspace.name}.jws
oracle.jdeveloper.project.name=${project.viewcontroller.name}
oracle.jdeveloper.deploy.dir=${workspace}/${project.deploy.folder}
oracle.jdeveloper.ojdeploy.path=${env.ORACLE_HOME_12C3}/jdev/bin/ojdeploy${env.EXEC_SUFFIX}
oracle.jdeveloper.deploy.outputfile=${workspace}/${project.deploy.folder}/${oracle.jdeveloper.deploy.profile.name}

and the build.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!--Ant buildfile generated by Oracle JDeveloper-->
<!--Generated Aug 22, 2015 3:15:37 PM-->
<project xmlns="antlib:org.apache.tools.ant" name="FrkExtModel" default="all" basedir=".">
  <property environment="env"/>
  <property file="build.properties"/>
  <path id="library.ADF.Model.Runtime">
    <pathelement location="${oracle.commons}/modules/oracle.idm_12.1.3/identitystore.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/adfm.jar"/>
    <pathelement location="${oracle.commons}/modules/groovy-all-2.1.6.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/adftransactionsdt.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.view_12.1.3/adf-dt-at-rt.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/adfdt_common.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/adflibrary.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.xdk_12.1.3/xmlparserv2.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/db-ca.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/jdev-cm.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.ldap_12.1.3/ojmisc.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.share_12.1.3/commons-el.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.share_12.1.3/jsp-el-api.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.share_12.1.3/oracle-el.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.security_12.1.3/adf-share-security.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.security_12.1.3/adf-controller-security.jar"/>
    <pathelement location="${oracle.commons}/modules/javax.mail_2.0.0.0_1-4-4.jar"/>
  </path>
  <path id="classpath">
    <path refid="library.ADF.Model.Runtime"/>
  </path>
  <target name="init">
    <tstamp/>
    <mkdir dir="${output.dir}"/>
  </target>
  <target name="info">
    <echo level="info">build: env.ORACLE_HOME=${env.ORACLE_HOME_12C3}</echo>
    <echo level="info">build: env.WORKSPACE=${env.WORKSPACE}</echo>
    <echo level="info">build: workspace=${workspace}</echo>
    <echo level="info">build: install.dir=${env.ORACLE_HOME_12C3}</echo>
    <echo level="info">build: oracle.commons=${oracle.commons}</echo>
    <echo level="info">build: oracle.jdeveloper.ant.library=${oracle.jdeveloper.ant.library}</echo>
    <echo level="info">build: oracle.jdeveloper.ojdeploy.path=${oracle.jdeveloper.ojdeploy.path}</echo>
    <echo level="info">build: oracle.jdeveloper.deploy.dir=${oracle.jdeveloper.deploy.dir}</echo>
    <echo level="info">build: oracle.jdeveloper.deploy.profile.name=${oracle.jdeveloper.deploy.profile.name}</echo>
    <echo level="info">build: oracle.jdeveloper.workspace.path=${oracle.jdeveloper.workspace.path}</echo>
    <echo level="info">build: oracle.jdeveloper.deploy.outputfile=${oracle.jdeveloper.deploy.outputfile}</echo>
  </target>
  <target name="all" description="Build the project" depends="info,deploy,compile,copy"/>
  <target name="clean" description="Clean the project">
    <delete includeemptydirs="true" quiet="true">
      <fileset dir="${output.dir}" includes="**/*"/>
    </delete>
  </target>
  <target name="deploy" description="Deploy JDeveloper profiles" depends="init">
    <taskdef name="ojdeploy" classname="oracle.jdeveloper.deploy.ant.OJDeployAntTask" uri="oraclelib:OJDeployAntTask"
             classpath="${oracle.jdeveloper.ant.library}"/>
    <ora:ojdeploy xmlns:ora="oraclelib:OJDeployAntTask" executable="${oracle.jdeveloper.ojdeploy.path}"
                  ora:buildscript="${oracle.jdeveloper.deploy.dir}/ojdeploy-build.xml"
                  ora:statuslog="${oracle.jdeveloper.deploy.dir}/ojdeploy-statuslog.xml">
      <ora:deploy>
        <ora:parameter name="workspace" value="${oracle.jdeveloper.workspace.path}"/>
        <ora:parameter name="project" value="${oracle.jdeveloper.project.name}"/>
        <ora:parameter name="profile" value="${oracle.jdeveloper.deploy.profile.name}"/>
        <ora:parameter name="nocompile" value="false"/>
        <ora:parameter name="outputfile" value="${oracle.jdeveloper.deploy.outputfile}"/>
      </ora:deploy>
    </ora:ojdeploy>
  </target>
  <target name="compile" description="Compile Java source files" depends="init">
    <javac destdir="${output.dir}" classpathref="classpath" debug="${javac.debug}" nowarn="${javac.nowarn}"
           deprecation="${javac.deprecation}" encoding="UTF8" source="1.7" target="1.7" includeantruntime="false">
      <src path="src"/>
    </javac>
  </target>
  <target name="copy" description="Copy files to output directory" depends="init">
    <patternset id="copy.patterns">
      <include name="**/*.GIF"/>
      <include name="**/*.JPEG"/>
      <include name="**/*.JPG"/>
      <include name="**/*.PNG"/>
      <include name="**/*.cpx"/>
      <include name="**/*.dcx"/>
      <include name="**/*.ejx"/>
      <include name="**/*.gif"/>
      <include name="**/*.ini"/>
      <include name="**/*.jpeg"/>
      <include name="**/*.jpg"/>
      <include name="**/*.png"/>
      <include name="**/*.properties"/>
      <include name="**/*.sva"/>
      <include name="**/*.tag"/>
      <include name="**/*.tld"/>
      <include name="**/*.wsdl"/>
      <include name="**/*.xcfg"/>
      <include name="**/*.xlf"/>
      <include name="**/*.xml"/>
      <include name="**/*.xsd"/>
      <include name="**/*.xsl"/>
      <exclude name="build.xml"/>
    </patternset>
    <copy todir="${output.dir}">
      <fileset dir="src">
        <patternset refid="copy.patterns"/>
      </fileset>
      <fileset dir=".">
        <patternset refid="copy.patterns"/>
      </fileset>
    </copy>
  </target>
</project>

The files above are the original ones and can be run from the build console to get this

Great, we now have successfully enabled CI in the cloud for the ‘Framework Extension’ project. Well, there is something more to think about. Can’t we use the same ANT build scripts on the local machine too?

Yes, we can but we have to make some adjustments for this.

Now that we read the environment from the server the ANT script is running on to set the some of the variables we need to set these environment variables on the local machine too. this can be done easily by altering the jdev start file (Linux) or using a batch to first set the environment variables and then start jdev (Windows). Below is my changes jdev start script

#!/bin/bash

#=============================================================================
#  Launcher for Oracle JDeveloper 12c (12.1.2.0.0)
#=============================================================================

unset -v GNOME_DESKTOP_SESSION_ID
export MIDDLEWARE_HOME_12C3=/opt/jdev/12.1.3.0.0/Oracle/Middleware
export ORACLE_HOME_12C3=/opt/jdev/12.1.3.0.0/Oracle/Middleware/Oracle_Home/jdeveloper
export WORKSPACE=/data/development/ENTW_12.1.3.0.0
export EXEC_SUFFIX=
/opt/jdev/12.1.3.0.0/Oracle/Middleware/Oracle_Home/jdeveloper/jdev/bin/jdev $1

As you see I set the environment variables which are later read through the build.xml file before starting jdeveloper.
The one line
export EXEC_SUFFIX=
need special attention. It’s only necessary if you run JDev using different operating systems (Linux and Windows). The build file has one variable pointing to the the ojdeploy executable
oracle.jdeveloper.ojdeploy.path=${env.ORACLE_HOME_12C3}/jdev/bin/ojdeploy${env.EXEC_SUFFIX}
Users using Windows need to add the suffix ‘.exe’ to this variable as ojdeploy can’t be started otherwise under Windows.
The problem is that we can’t add it for Linux systems as they don’t know this suffix. The solution I found is to add ${env.EXEC_SUFFIX} to the executable and set it to an empty string for Linux systems. For Windows systems you have to set this environment variable to ‘.exe’. For this I use a batch file where I use
~~~setx EXEC_SUFFIX .exe~~~
before starting JDev. In the same batch I set the other variables too

setx ORACLE_HOME_12C3 r:\Java\12.1.3.0.0\Oracle\Middleware\jdeveloper
setx MIDDLEWARE_HOME_12C3 r:\Java\12.1.3.0.0\Oracle\Middleware
setx EXEC_SUFFIX .exe

Alt NOTE
To make the build files work under Windows and Linux and iOS add an environment variable defining the suffix for executable files.

One final trick is to set the workspace directory. The build.properties file has one more environment variable workspace=${env.WORKSPACE} which we need to set.
As the workspace isn’t fix on a local machine, at least if you have more than one workspace, you can’t set this variable before you start JDev. This has to be done per workspace, when you change the workspace.
JDev has a solution for this in the ANT properties section

ANT Project Properties

ANT Project Properties


You can shoose from different variables JDev sets according to the workspace and project you are working with.
JDeveloper Variables

JDeveloper Variables

Alt NOTE
Set the env.WORKSPACE environment variable in the ANT properties of the project.

This concludes this part of the series. In the next post we finish the feature ‘feature-setup-build’ by introducing the code review function of the Oracle Developer Cloud. This will be followed by a post about building a simple ADF application with a UI which you use to show the Continuous Delivery (CD) option of the Oracle Developer Cloud.

Pitfalls when using libraries of newer version than shipped with JDeveloper or WebLogic Server

A question on JDeveloper & ADF OTN forum cought my attention. A user wanted to use a method of the Apache Commons-IO library named FileUtils.getTempDiretory() but got an error when he tried to use code completion or when he tried to compile the code. The problem was that the compiler (or code completion) did not pick up the right java class from the library even as it was installed in the project a library.
As the original code used belongs to one of my samples I was interested in finding a reason for this behavior as I could see no obvious reason for this behavior.

An inspection of a provided test case quickly revealed the problem and a solution was found too. This blog is about the problem and the solution to it. Lets start with building a test case:


The test case had a model project which used a couple of libraries which we add too to make this sample as close as possible to the test case.
 Model Project Properties

Model Project Properties


There is no code whatsoever used in the model project just the libraries are defined!

To make use of the FileUtils.getTempDiretory() method we have to first download the Apache Commons-IO in a version higher then 2.0. The current version is 2.4 which you get from the given link. Once you unzip the zip (or tar.gz) to a directory of your choice we create a new library for JDeveloper (Tools->Manage Libraries…)

We add This new library to the view controller project


Next is to create a java bean where we try to use the FileUtils.getTempDiretory() method

Here we see the problem mentioned in the OTN question. The FileUtils.getTempDiretory() does not show up at all. The JavaDoc of the Apache Commons-IO 2.4 package shows that the method is available since version 2.0
JavaDoc of FileUtils Class

JavaDoc of FileUtils Class


If we try to compile the code we get an compilation error as seen in the last image.

What is the problem?
Well, it looks like there is another version of the Apache Commons-IO library already loaded in the classpath which gets loaded first. Once a library or class is loaded, another version of the same class will not overwrite the existing one.
First thing we can try is to move the new commons-io library to the top of the list of libraries.
In the test case presented here, this doesn’t work. We still get the same error. So there are libraries loaded before the view controller project libraries come to play.
Remember we added some libraries to the model project even as there is no code in the project at all?
Because the view controller project has dependency defined to the model project when we create an Fusion Web Application by default, libraries of the model project are loaded before the view controller projects.
We have can solve the problem in multiple ways:
1. remove the dependency to the model project. This is not recommended as it would mean that we have to build the model project ourselves if we have to change something in the model and want to run the application.
2. find the library which loads the FindUtils class and see if we can remove it (not all libraries are needed).
3. add the new Apache Commons-IO library to the model project and move it up front. This should load the newer version of the FindUtils class before any other.

Solution 1 isn’t really one. Solution 2 is possible and I’ll blog about it later. For this blog we use solution 3.

Solution
All we have to do is to add the Apache Commons-IO 2.4 library to the model project and move to the top of the list.

Model Project Properties with Commons-IO

Model Project Properties with Commons-IO


If we now rebuild the workspace we see that to error is gone
No Compilation Error

No Compilation Error


The code completion still shows the method red underlined. This is a bug in JDeveloper which doesn’t pick up the right library. Anyway, the compiler will use the right library and we can compile the application.

Now we add another method to the FileBean which returns the path to the temporary directory. This we use in a page index.jsf to show it on the ui.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html>
<f:view xmlns:f="http://java.sun.com/jsf/core" xmlns:af="http://xmlns.oracle.com/adf/faces/rich">
  <af:document title="index.jsf" id="d1">
    <af:form id="f1">
      <af:panelGridLayout id="pgl1">
        <af:gridRow height="50px" id="gr2">
          <af:gridCell width="100%" halign="stretch" valign="stretch" id="gc1">
            <!-- Header -->
            <af:outputText value="Preferred Package Test" id="ot1" inlineStyle="font-size:x-large;"/>
          </af:gridCell>
        </af:gridRow>
        <af:gridRow height="100%" id="gr1">
          <af:gridCell width="100%" halign="stretch" valign="stretch" id="gc2">
            <!-- Content -->
            <af:outputText value="Tempdir path = #{FileBean.tempDir}" id="ot2"/>
          </af:gridCell>
        </af:gridRow>
      </af:panelGridLayout>
    </af:form>
  </af:document>
</f:view>

When we run the application we get an exception

    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:263)
Caused by: java.lang.NoSuchMethodError: org.apache.commons.io.FileUtils.getTempDirectoryPath()Ljava/lang/String;
    at de.hahn.blog.preferredpackages.view.beans.FileBean.getTempDir(FileBean.java:16)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)

Why’s that?
The application compiled without an error and we still get a NoSuchMethodError. The reason for this is that when we start the WebLogic Server the older version of the Apache Commons-IO jar is loaded first, blocking loading of the newer version we need to get to the FileUtils.getTempDirectoryPath() method.
To allow the server to load our newer version of the jar we need to change a descriptor named weblogic-application.xml which is specific for WebLogic Server. For other servers there exist other descriptors allowing the same.
In this descriptor we add a preferred package for the org.apache.commons.io package. Open the weblogic-appliaction.xml descriptor and select the ‘Class Loading…’ node.

Application Descriptors: weblogic-application.xml

Application Descriptors: weblogic-application.xml


Here we enter the package name org.apache.commons.io to the ‘Application Preferred Libraries’ section.

to get this result in the source view of the descriptor:

    <prefer-application-packages>
        <package-name>org.apache.commons.io</package-name>
    </prefer-application-packages>

After restarting the application the index.jsf page show up OK

Running Test Page

Running Test Page

You can download the sample application which was build using JDeveloper 12.1.3 from GitHub.

Installing JDeveloper 11.1.1.7.0 from the Generic Installer Jar on 64bit Windows System

If you have installed JDev 11.1.1.7.0 lately, which I strongly recommend, you may have noticed, that the windows installer jdevstudio11117install.exe still ships with jdk160_24. Please don’t ask why Oracle don’t includes a JDk 1.7, I don’t know.
Well, it’s time to use JDK1.7 on my WIn7x64 system so I loaded hte jdevstudio11117install.jar which is a lot bigger (1.9GB) but comes without a bundeld JDK. As I have already installed JDK 1.7.0_17 on my system I pointed the installation to this jdk when I asked during the installation.
Everything went smooth and i took only a couple of minutes to install JDev and generate the embedded WLS 10.3.5 instance.

However, when I tried to start the embedded WLS instance I got the following error message

*** Using port 7101 ***
r:\jdeveloper\system\system11.1.1.7.40.64.93\DefaultDomain\bin\startWebLogic.cmd
[waiting for the server to complete its initialization...]
.
.
JAVA Memory arguments: -Xms256m -Xmx512m
.
WLS Start Mode=Development
.
CLASSPATH=...
.
PATH=...
.
***************************************************
*  To start WebLogic Server, use a username and   *
*  password assigned to an admin-level user.  For *
*  server administration, use the WebLogic Server *
*  console at http:\\hostname:port\console        *
***************************************************
starting weblogic with Java version:
<strong>Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Unrecognized option: -jrockit</strong>
Starting WLS with line:
...
Process exited.

Hm, ‘Unrecognized option: -jrockit‘, how’s that? I’m running Sun JDK!
Right at the beginning of the server start we see the command used to start the server (the path may be different on your system)
r:\jdeveloper\system\system11.1.1.7.40.64.93\DefaultDomain\bin\startWebLogic.cmd
A look into this command shell reveals that another command shell script is called
r:\jdeveloper\system\system11.1.1.7.40.64.93\DefaultDomain\bin\setDomainEnv.cmd
In this script we find the problem

...
set BEA_JAVA_HOME=C:\Program Files\Java\jdk1.7.0_17

set SUN_JAVA_HOME=


if "%JAVA_VENDOR%"=="Oracle" (
	set JAVA_HOME=%BEA_JAVA_HOME%
) else (
	if "%JAVA_VENDOR%"=="Sun" (
		set JAVA_HOME=%SUN_JAVA_HOME%
	) else (
		set JAVA_VENDOR=Oracle
		set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_17
	)
)
...

As you see hte BEA_JAVA_HOME is set and if you put an
echo %JAVA_VENDOR%
before the if statement you see that the vendor is null. This sets the JAVA_HOME correct, but sets the JAVA_VENDOR to ‘Oracle’. This then adds the wrong option -jrockit to the command line later on in the startWebLogic.cmd script.

Now that we know that the solution is to make a small change to the
r:\jdeveloper\system\system11.1.1.7.40.64.93\DefaultDomain\bin\setDomainEnv.cmd
script. We only have to set the SUN_JAVA_HOME and set the JAVA_VENDOR to ‘Sun’

set BEA_JAVA_HOME=

set SUN_JAVA_HOME=C:\Program Files\Java\jdk1.7.0_17
set JAVA_VENDOR=Sun

After this change the embedded WLS server starts without a problem.

JDeveloper & ADF: Carefully Select the Data Control Scope of Bounded Task Flows

A customer asked me to look into an error which showed up in one of their applications. Without going into the details of real use case I like to bring this issue to your attention as it might happen to you too.

Use Case
I set up a mock use case to show the problem as this: A page (.jspx or .jsf) includes one (or more) other task flows as a region. The base page retrieves some data using a method call exposed in the data control, which should be displayed in the region for information purpose.

Implementation
If the task flows share their data controls this is not a big deal to implement this. You can download the sample using the link provided at the end of this blog. The sample uses the HR schema and was build using JDev 11.1.1.5.0 and was additional tested with JDev 11.1.1.1.6.0 and JDev 11.1.2.2.0, which show the same behavior.

On the base page I set up an inputText which I use to pass a parameter to the method (callMeTest) which retrieves some info from the application module. The callMeTest method simply returns the passed parameter together with a ‘nice’ message:

    public String callMeTest(String name) {
        _logger.info("Called with: "+name);
        return "Call me Test "+name;
    }

The return value is then displayed on the base page at the bottom under the button and should be displayed in the region, under the table, too. The sample just uses one region. When no value is present ‘****’ is used as parameter. The image below shows the application after starting it.

Start Screen

Start Screen

After entering a value into the inputText field below the table and hitting the ‘callMeTest’ button underneath it, you see that the return value is displayed below the button on the base page and under the table inside the region. If the button is hit with another value, both values are updated.

After entering a value and hitting the button

After entering a value and hitting the button

Nothing unusual so far. Now, for some unknown reason, after a change to another part the application, that functionality did not work any longer. The value in the base page still updates after the call to the method, but the value in the region stopped updating.

Screen after next deployment

Screen after next deployment

The reason for this behavior is a simple one. A look into the task flow properties of the region, revealed that the checkmark for the ‘Share data controls with calling task flow’ was not set, meaning that the task flow get its own data control frame. The result is that the method outcome from the base page is not visible in the region.

TaskFlow properties (1)

TaskFlow properties (1)

The question was how did this happen, when the change which results in the new deployment had nothing to do with this part of the application?

Analysis
It turned out, that when you create a new bounded task flow this property value is set to ‘default’. This is shown in the ‘Overview’ of the task flow as bluish shade in the check box. No checkmark is set and a look into the source reveals that the whole section

    <data-control-scope>
      <....../>
    </data-control-scope>

is just missing from the XML file.

TaskFlow after creation

TaskFlow after creation

Once you click on this property in the property editor you can just switch between ‘isolated’ or ‘shared’.

TaskFlow properties (2)

TaskFlow properties (2)

The only possible way to get the bluish shade back is to delete the section in the source view of the task flow.

TaskFlow properties in 'Source Mode'

TaskFlow properties in ‘Source Mode’

So this checkbox has three states ‘bluish’, ‘isolated’, and ‘shared’. Well, there is a forth state which you get if you open the property editor in source mode and select ‘default’. The following table shown all states together with their meaning:

State  Meaning
Bluish  Shared
Check marked  Shared
Unchecked not bluish  Isolated
Data-control-scope empty  Isolated

While the application works according to the meaning of the flag, I find it not intuitive how JDev handles this setting. The programmer who made the change to the application clicked this property, but meant to do so on a different task flow. So he unchecked the ‘Share data controls with calling task flow’ property as he remembered that it was not set before.

Recommendation
My advise is to set the flag whenever you create a task flow so you know which share mode the task flow uses. This avoids errors like the one described in this blog.

UPDATE
In the meantime Chris Muir raised the issue with the UX specialists (Oracle intern) and Bug 14390576 has been raised for this issue.
Thank you Chris!

The sample uses the HR schema and was build with JDeveloper 11.1.1.5.0, tested with 11.1.1.6.0 and 11.1.2.2.0 . You can download the sample work space form ADF Samples: Source Code

JDeveloper: Controlling which Resources (Files) are Copied into the Projects Output Directory

Some projects need resource files available in the output directory together with the class files. This is a fairly common task, however it’s not obvious how to archive this for all types of resources.

IF you never have had the problem, that a resource file you used in your project did not turn up in the output directory, you probably have used only default resource files like ‘properties’, ‘wsdl’ or ‘XML’ files. These files are copied into the output path by default.

Lets assume you have a resource e.g. a tiff file (*.tiff) or a TrueType font (*.ttf) which you need in your project and finally in the jar or adflib you build from the project. Lets add a dummy file ‘MyFont.ttf’ in a new folder named ‘res’ under the base path of the model projcect ‘de.hahn.blog.controlresourcefiles’. After this the model application looks like

Model Project after adding Font File

Model Project after adding Font File

No problem with this. Now if you compile the model project and check the output path Q:\QT\BlogControlResourceFiles\CRFModel\classes in this sample, you’ll notice that the folder ‘res’ and file ‘MyFont.ttf’ is not in the directory tree

Output Path after Compile

Output Path after Compile

If you check the path configuration of the project, it shows that the folder and the file should have been there

Project Path

Project Path

Well, the problem is an other configuration for the project. If you check the compiler node in the project properties you see that there is a filter which defines which file types are copied into the output path of the project

Project Compiler  Settings

Project Compiler Settings

As you see there is no entry for type ‘.ttf’ which means that files with this suffix are not copied into the output directory. The solution to the problem is to simply add the suffix ‘.ttf’ to the filter and compile the project again. After this the file ‘MyFont.ttf’ can be found in the projects output directory.

If you have any resource of a type (file suffix) you want to automatically copied into the projects output directory, you simple add the missing suffix to the filter.

JDeveloper: Case Insensitive Search and Performance

A couple of days ago Frank Nimphius published a new ADF Insider Essential video about Search Forms Customization where he also showed how to implement case insensitive searches. While the tip how to do this is fine, he did not mention the bottleneck involved in doing so. Yesterday, while writing up this blog I came across this blog ‘ADF ViewCriteria performance impact’ by Raman Nanda who summarized the same issue. The last statement in his blog is the starting of this blog:

Note:Also don’t choose to ignore null values for predicates that are required and create proper indexes on the table structure depending upon how you filter results. For ex: If predicate is upper(ename)=upper(:bvar) then create a index on upper(ename) .

Lets start with a look on a view criteria definition in JDeveloper 11.1.2.1.0. the image below shows the definition of a simple view criteria to search for employees who’s names start with a given bind variable. When you first add items to the view criteria both check boxes ‘Ignore Case’ and ‘Ignore NULL Values’ are checked.

ViewCriteria Definition: Ignore Case and Ignore Null

ViewCriteria Definition: Ignore Case and Ignore Null


A close look at the ‘View Object Where Clause’ part reveals that the ‘Ignore Case’ part of the query is not visible in JDev 11.1.2.1.0. This is a bug which I’m going to file in the near future. Before going into detail with the query lets uncheck the ‘Ignore NULL Values’ to see the final criteria:
ViewCriteria only 'Ignore Case'

ViewCriteria only 'Ignore Case'


Running the application module in the tester reveals the final query as (copied from the log window)

[104] SELECT Employees.EMPLOYEE_ID,         Employees.FIRST_NAME,         Employees.LAST_NAME,         Employees.EMAIL,        
             Employees.PHONE_NUMBER,         Employees.HIRE_DATE,         Employees.JOB_ID,         Employees.SALARY,         
             Employees.COMMISSION_PCT,         Employees.MANAGER_ID,         Employees.DEPARTMENT_ID,         
             Employees.ACTION_COMMENT 
             FROM EMPLOYEES Employees 
             WHERE ( ( ( (UPPER(Employees.LAST_NAME) LIKE UPPER( :bindLN || '%') ) ) ) )
[105] Bind params for ViewObject: [de.hahn.blog.vcinsesitivesearch.model.dataaccess.EmployeesView]VCISAppModule.EmployeesView1
[106] Binding param "bindLN": K

Here you see that the ‘Ignore Case’ results in calling SQL UPPER'(…) on the bind parameter as well as on the row attribute. When you copy this query and run it in a SQL worksheet it returns the right results. However, in this bog we are more interested in the execution plan of the query. This is shown in the below image:

Execution Plan Without Index

Execution Plan Without Index


The interesting thing is that the result is reached by a full table scan, which you see as the option is ‘FULL’ for table access. This is not a problem if the table contains only a small number of rows, but if you work on large tables with 10000+ rows it’ll take ages (OK, it’s notable longer then you would expect) to execute.
If you only have defined the normal index on the LAST_NAME column

create index normal_ln_idx on employees (last_name);

the plan doesn’t change at all. This is exactly what Raman Nanda meant in his blog. You need to create a function based index on the LAST_NAME column. Here is the SQL to do so:

create index upper_ln_ix on employees (UPPER(last_name));

Running the query again after creation of the new index results in

Execution Plan with UPPER Index

Execution Plan with UPPER Index


As yo ucan see the table now is accessed via the ‘upper_ln_ix’ index we created. This speeds things up in large tables.

To summarize this blog: you should, as part of your testing, check the execution plans of the queries executed by your application. This can result in a huge improvement of the performance. You should ask your DBA to help you with this task. There are tools readily available to the DBA to help getting information about the queries executed by your application.

Save (most of) your changes to the JDeveloper IDE

Under some circumstances you may need to rename or remove your system11.x.x.x folder to overcome errors with the IDE which can’t be solved otherwise. I blogged about this How to find and reset the system11.x.x.x folder for a JDeveloper installation.
However, this means that you loose all of the changes you made to IDE, e.g. connections to DBs, code templates and many more.
In the current version or JDeveloper there is no feature to save all the changes you made with a simple export or click on a button. An ER for this is about to be filed.

Until we see this ER implemented you need to store the changes you made yourself. First of all we need to know all the places were changes can be saved in a file or exported into a file. I put all those files under source control. This makes them available for other developers in the same team and allows to hold different configurations for different or the same JDeveloper version. This blog post lists all the places I know. If you know any other place, please drop a comment so that I can include it here.
To my knowledge the locations below are working for all JDeveloper version from 11.1.1.x up to the current version 11.1.2.1.0.

There are three locations where you can save your changes

  1. Recource Palette
  2. Preferences
  3. File menu

Lets start with the Resource Palette:

Resource Palette 1

Resource Palette 1


This will bring up
Resource Palette 2

Resource Palette 2


This dialog allows you to save all the connection to DBs and Weblogic Servers you have defined as well as Catalogs. All you have to do is to specify a path and a file name to store the information.

Next are the Preferences. Here are a couple of places where you can export your changes.
Audit Profiles:

Audit Profiles

Audit Profiles

Code Editor – Code Style

Code Editor - Code Style

Code Editor - Code Style

Code Editor – Code Templates

Code Editor - Code Templates

Code Editor - Code Templates

Code Editor – Syntax Colors

Code Editor - Syntax Colors

Code Editor - Syntax Colors

Database – SQL Formatter

Database - SQL Formatter

Database - SQL Formatter

Database – SQL Formatter – Oracle Formatting

SQL Formatter - Oracle Formatting

SQL Formatter - Oracle Formatting

Database – SQL Formatter – Other Vendors (each vendor can be saved)

 Database - SQL Formatter - Other Vendors

Database - SQL Formatter - Other Vendors


 Shortcut Keys

Shortcut Keys

Versioning – Comment Templates

Versioning - Comment Templates

Versioning - Comment Templates

Finally the ‘File’ menu which mainly allows to export the connections to the source control system you use

File - Export

File - Export

JDev 11.1.2.1.0: Dealing with ADF_FACES-60003 Error: Component with ID: r1:1:cb1 not registered for Active Data.

The last couple of weeks I saw some questions on OTN JDev forum dealing with file and image handling in ADF applications. All of the needed information to do this is already published in various blog posts and tutorials, still I did not find a post covering all aspects with a single demo application.

I’m in the progress of writing a mini series about file handling (upload and download) and image handling in ADF applications providing exactly this demo application. If you are interested in this stay tuned, as the first part is almost ready to publish.

Now, while I assembled the demo application I stumbled upon this error:

java.lang.IllegalStateException: ADF_FACES-60003:Component with ID: r1:1:cb1 not registered for Active Data.
	at oracle.adfinternal.view.faces.activedata.PageDataUpdateManager.unregisterComponent(PageDataUpdateManager.java:600)
	at oracle.adfinternal.view.faces.context.RichPhaseListener.handleStartAndStopActiveData(RichPhaseListener.java:502)
	at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:479)
	at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:204)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
	at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
	at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
	at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
	at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:173)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:122)
	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:468)
	at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)
	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:468)
	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:293)
	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:199)
	at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at weblogic.servlet.utils.FastSwapFilter.doFilter(FastSwapFilter.java:66)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
	at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413)
	at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:94)
	at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:161)
	at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:136)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
	at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
	at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
	at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
	at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
	at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
	at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
...

It happened when I used a af:fileDownloadActionListeneron a detail page fragment and navigated back to the master page fragment. As I never saw the error before and did not use ‘Active Data’ anywhere in my demo, I started digging.

There are some members of OTN hitting the same error (may be not under the exact same conditions) as this thread shows.
The thread points to an older post which mentions that this is caused by the bug 9218151 and is fixed in JDev 11.1.2.0.0. As I use JDev 11.1.2.1.0 this should not happen, or I see a regression of the bug in JDev 11.1.2.1.0. The bug database did not help either, as there is very little information on the bug itself.
The solution given in the thread to use a custom error handler (and ignore the error) did not seem right to me. I did not try the other solution to write a custom tag either, as it looks like overkill to me.

The normal debugging of this problem didn’t get me further to a solution. I tried a couple of things and even was able to get around the error with some hacks I will not publish here.

Luckily I met Frank Nimphius at the DOAG2011 and ask him about this bug (that’s what such events are for :)). He gave the right pointer to solve the problem.
With JDev 11.1.2.0.0 a new default ‘change event policy’ was introduced to the iterators and components. Now the policy is ‘ppr’ and not ‘none’ as before.
Jobinesh had blogged about the new ‘change event policy’ and its meaning here.

As I couldn’t reproduce this behavior in JDev 11.1.1.5.0 Franks suggestion was to set the change event policy back to none. After doing exactly this the error is gone, the application runs as expected.

The new policy can be changed (back to the old behavior) on a global level for applications you are building new under JDev 11.1.2.x. To do this open the adfc-config.xml file from the ‘Application Resources:

adfc-config.xml

adfc-config.xml

change to the ‘Overview’ tab and select the ‘Model’. Here you remove the selection from the check box:

adfc-Config.xml Change Event Policy

adfc-Config.xml Change Event Policy

If you already have done some work in your project, e.g. used some views on an UI page, you have to change the iterators one by one. For this open the bindings of the page and select an iterator:

Change Event Policy on Iterator

Change Event Policy on Iterator

You may let the default ‘change event policy’ be ‘ppr’ if you like, as there are some advantages (there must be a reason why Oracle changed it in the first place). Only if you hit the error you can change the policy for the iterators involved. Keep in mind, that changing the policy later may have some side effects to your existing pages. It’s up to you to decide and test this.

I’ll file an SR for this just to make sure that Oracle looks into this again. For me it looks like a bug as I don’t understand why I get an error at all.

JDeveloper Versions vs. Weblogic Server Versions

UPDATE 21-Dec-2012: added info for JDev 11.1.2.x running on WLS 10.3.5 to match the Certification Matrix
UPDATE 29-Nov-2012: added note for new JDev 11.1.1.6.0 Build 6229 released Nov-2012
UPDATE 13-Jul-2013: added info for JDev 12c released 10-Jul-2013
UPDATE 26-Jun-2014: added info for JDev 12cR1 (12.1.3) released 26-Jun-2014

The last couple of days more people are trying to run ADF applications build with JDeveloper of version X on a Weblogic Server with a different ADF Runtime version Y installed.

To make it clear, this will not work!

You need to make sure that the ADF Runtime versions of  JDeveloper and Weblogic Server match. Next thing is that you can’t install the ADF Runtime on any Weblogic Server you like. The ADF Runtime will only work with a specific Weblogic Server. As each JDeveloper version comes with its own ADF Runtime version, there is a direct connection between JDeveloper and Weblogic Server.

To help you to use the right combination use the below table:

JDeveloper (ADF Runtime) Weblogic Server Info
11.1.1.2.0 10.3.2
11.1.1.3.0 10.3.3
11.1.1.4.0 10.3.4
11.1.1.5.0 10.3.5
11.1.1.6.0 10.3.5, 10.3.6 Integrated WLS is 10.3.5, stand alone WLS can be 10.3.5 or 10.3.6 (see Chris Muir on adf runtime 11.1.1.6.0)
Important Note: there are two releses of JDev 11.1.1.6.0 out. The first one release Feb 2012 (Build 6192.1) and the second one Nov 2012 (Build 6229). Both use the same ‘ADF Runtime Installation’ so there in no new ‘ADF Runtime’ installation available or needed. Read Release Notes for more information on this.
11.1.1.7.0 10.3.5, 10.3.6 Integrated WLS is 10.3.5, stand alone WLS can be 10.3.5 or 10.3.6 (see Chris Muir on adf runtime 11.1.1.6.0)
11.1.2.0.0 10.3.5 + Sherman patch Only available via MOS: patch  #12611176 and  patch #12556632; requires ADF 11.1.2.x patches onto Application Development Runtime 11.1.1.5.x
11.1.2.1.0 10.3.5 + Sherman patch UPDATE1 Only available via MOS: patch #12979653 and patch #12917525; requires ADF 11.1.2.x patches onto Application Development Runtime 11.1.1.5.x
11.1.2.2.0 10.3.5 + Sherman patch UPDATE2; 10.3.6 + Sherman patch UPDATE2 Only available via MOS: patch #13656274 and patch #13656372 (see Patch Numbers for ADF Runtime Libraries Update to 11.1.2.2.0 for more info); running on WLS10.3.5 requires ADF 11.1.2.x patches onto Application Development Runtime 11.1.1.6.x
11.1.2.3.0 10.3.5 + Sherman patch UPDATE3; 10.3.6 + Sherman patch UPDATE3 Only available via MOS: patch #14582286 (ADF) and patch #14582309 (WebCenter); running on WLS10.3.5 requires ADF 11.1.2.x patches onto Application Development Runtime 11.1.1.6.x
11.1.2.4.0 10.3.5 + Sherman patch UPDATE4; 10.3.6 + Sherman patch UPDATE4 Only available via MOS: patch #16546129 (ADF) and patch #16546157 (WebCenter); running on WLS10.3.5 requires ADF 11.1.2.x patches onto Application Development Runtime 11.1.1.6.x
12.1.2.0.0 12.1.2.0.0 WLS 10.3.5+ can be used if no ADF is used in the application!
Running a standalone WLS12.1.2.0.0 needs a Oracle DB 11.1.0.7+, Oracle DB 11.2.0.3+ or Oracle DB 12.1.0.1+
12.1.3.0.0 12.1.3.0.0 WLS 10.3.5+ can be used if no ADF is used in the application!
Running a standalone WLS12.1.3.0.0 needs a Oracle DB 11.1.0.7+, Oracle DB 11.2.0.3+ or Oracle DB 12.1.0.1+

There is no backward or forward compatibility!

You don’t need to try, I’ve tested most but not all combinations and run into trouble whenever I mixed versions.

For my tests I used used a small ADF application based on the HR schema.The UI consists of an af:query with a panelCollection for the result table and abounded task flow for editing a row in a popup.

The application was build on JDeveloper under Window 7, the resulting ear file was deployed (using the WLS console) on the Weblogic Server on a Linux box.

The ADF Runtime  installed on the WLS was downloaded from here. The WLS  installed on the Linux box was downloaded from here. I used the “Oracle WebLogic Server 11gR1 (10.3.5) + Coherence – Package Installer” and installed the WLS without  Coherence. After installing WLS the ADF Runtime installation was applied.