Case Study: Backporting a JDeveloper Project from11gR2 to 11gR1

I got a couple of queries to backport my file and image handling sample, which was built using JDeveloper 11.1.2.x version, to JDeveloper 11.1.1.x version. This I have done and like to share the steps on how to do this.

Here are the general steps:

  1. copy the workspace from 11gR2 into a fresh folder which you should onöy access with 11gR1. It’s essential to don’t open one workspace with different workspaces as this might change descriptors and or files.
  2. open the ‘.jsw’ file in 11gR1. If you get a message if you want to migrate answer ‘yes’
  3. recompile the model project.
  4. make the necessary changes to the viewController project files: ui pages and descriptors
  5. Test the application

As base for this case study we use the sample which is the final sample from the Part 3.

1) unzip the sample into a fresh folder. We use the same folder names from the zip archive, but use a different base directory (backport in this case)
2) The images below show the steps to take after copying the files into the backport folder and opening the ‘.jws’ file. Don’t be fooled by the wizard which tell you that the files are converted from jsf1.0 to jsf1.2. Somehow hte wizard only knows that that the files are not jsf1.2 so it assumes that they are jsf1.0.

3) The database project don’t need any attention. The model project can just be recompiled. Here are the last lines after the rebuild. If you like you can test application module using the application module tester

Validating Business Component:
  copying de/hahn/blog/uldl/model/businessobjects/Catalog.xml to output directory
Updated file:/Q:/backport/BlogUploadDownload/ULDLModel/classes/META-INF/adfm.xml
[7:11:42 PM] Successful compilation: 0 errors, 0 warnings. 

4) Now we have to make some obvious changes to the ViewController project. Fist we have to check if the ui pages are built using JSPX pages of JSF pages. A look into the public_html folder reveals that there is only one page (Catalog.jsf) which was built as JSF page. In a first step we rename the file to Catalog.jspx. Fragments have the suffix ‘.jsff’ in both versions, but are based on different schemas. However, we don’t need to rename the fragments.
Now we refresh the viewController project to see the new jspx file.

Refresh Project

Refresh Project

When we open the file we’ll see an error which is hte result that we tried to open a jsf (renamed only to jspx) page in 11gR1.
Error opening the Catalog.jspx

Error opening the Catalog.jspx

We ignore the error and continue our work. To fix the error we have to look into the file (source) and see that the jsf page uses a different root element:

<f:view xmlns:f="" xmlns:af="">

whereas a jspx page uses

<jsp:root xmlns:jsp="" version="2.1" xmlns:f="" xmlns:h=""
  < contentType="text/html;charset=UTF-8"/>
<f:view xmlns:f="" xmlns:af="">

After changing this root element and adding the close tag, the whole page look like

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="" version="2.1" xmlns:f="" xmlns:h=""
    < contentType="text/html;charset=UTF-8"/>
    <f:view xmlns:f="" xmlns:af="">
        <af:document title="Catalog.jspx" id="d1">
            <af:form id="f1" usesUpload="true">
                <af:panelStretchLayout topHeight="50px" id="psl1">
                    <f:facet name="top">
                        <af:outputText value="Upload Download Test" id="ot1" inlineStyle="font-size:xx-large;"/>
                    <f:facet name="center">
                        <af:region value="#{bindings.catalogtaskflowdefinition1.regionModel}" id="r1"/>
                        <!-- id="af_one_column_header_stretched"  -->

We still see red marks in the right side gutter of the file. These are because we have not jet changes the libraries used by the project. After removing the JSF2.0 library we use the ‘Code Assist’ function of JDeveloper to add the correct JSF1.2 tag libs and libraries.

You may have to close JDeveloper and reopen it again to get rid of the red marks. After this you can open hte Catalog.jspx file in design mode:
Migrated Catalog.jspx

Migrated Catalog.jspx

The next step is to look into the ‘.jsff’ fragments. These too are using a different schema. This is the JSF2.0 fragment which uses a tag:

<?xml version='1.0' encoding='UTF-8'?>
<ui:composition xmlns:ui=""

The JSF1.2 fragment uses a jsp:root element instead:

<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="" version="2.1" xmlns:af="" xmlns:f="">

Changing the ui:component tag to the jsp:root tag (don’t forget to change the end tag) the fragments can be opened in design mode too. Depending on the components you have used in your may have to change some ui components to get your page to work.
Next step is to adjust the Databindings.cpx which still holds a link to the Catalog.jsf page.

Old Databindings.cpx

Old Databindings.cpx

Open the file in source mode and change the ‘Catalog.jsf’ to ‘Catalog.jspx’. Next we have to check the ‘adfc-config.xml’ which holds a reference to the ‘Catalog.jsf’ page. This we change to ‘Catalog.jspx’.
Now we are ready to try to run the backported app the first time. We check the DB connection first, then run the application.

<20.05.2013 20:58 Uhr MESZ> <Error> <J2EE> <BEA-160197> <Unable to load descriptor P:\jdeveloper\system\system11.\o.j2ee\drs\BlogUploadDownload/META-INF/weblogic-application.xml of module BlogUploadDownload. The error is weblogic.descriptor.DescriptorException: Unmarshaller failed
	at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(
	at weblogic.descriptor.BasicDescriptorManager.createDescriptor(
	at weblogic.application.descriptor.AbstractDescriptorLoader2.getDescriptorBeanFromReader(
Caused by: com.bea.xml.XmlException: weblogic.descriptor.BeanAlreadyExistsException: Bean already exists: "weblogic.j2ee.descriptor.wl.LibraryRefBeanImpl@eadc995c(/LibraryRefs[[CompoundKey:]])"
	at com.bea.staxb.runtime.internal.util.ReflectionUtils.invokeMethod(
	at com.bea.staxb.runtime.internal.RuntimeBindingType$BeanRuntimeProperty.setValue(

This error points to one of the descriptors we did not check up to now. The ‘/LibraryRefs[[CompoundKey:]]’ is defined in the weblogic-application.xml file which we find ‘Application Resources’->’Descriptors’->’META-INF’ node.



Here we see that there are multiple entries for the same listeners and library-ref entries. These entries are getting duplicated each time you open the project (or restart JDeveloper). The reason for this is that the ‘xsi:schemaLocation’ is pointing to the wrong version ‘1.1’ (and location) in this case. The correct version for the 11gR1 is ‘1.0’. We replace the wrong schema with the correct one and remove the duplication entries.

<weblogic-application xmlns:xsi=""

Before we run the application again we check need to check the web.xml which contains a couple of entries which are not needed using 11gR1.
There ‘context-param’s javax.faces.PARTIAL_STATE_SAVING,, javax.faces.FACELETS_VIEW_MAPPINGS, javax.faces.FACELETS_SKIP_XML_INSTRUCTIONS, javax.faces.FACELETS_SKIP_COMMENTS, javax.faces.FACELETS_DECORATORS and javax.faces.FACELETS_RESOURCE_RESOLVER should be removed.
After these changes the application is ready to run.
5) Test run the application

Running Backported Application

Running Backported Application

If you like to use hte new skyros skin you neet to alter the trinidad-config.xml to:

<?xml version="1.0" encoding="UTF-8"?>
<trinidad-config xmlns="">

The last things to check is the ‘transaction isolation level’ of the task flows and the ‘ChangeEventPolicy’ of the iterators. The default ‘ChangeEventPolicy’ has been changed for 11gR2 applications to ‘ppr’ whereas it was ‘none’ for 11gR1. This change might not be visible at first, but you may notice some flicker in the table of the sample. This is the result of the new ‘ChangeEventPolicy’. If you check it back to none, you have to app the partial triggers to the components yourself. This is done in the sample which comes with Part 4 of the file and image handling sample.

There sure are more things to change, which I did not mention. This is because I did not need to change them ot did not find them. If you come across suhc a missing thing, please drop me a note so that I can add this to this article.

Patch Numbers for ADF Runtime Libraries Update to

After the release of the new JDev version I ask support for the patch numbers for the ‘Sherman Update 2’, which seams to be the official name.
Support just answered my question:

The 2 patches are :


But I need confirmation if it can be installes on top of WLS
as from the crertification matrix it is only certified on top of WLS :
Oracle JDeveloper Certification Information

So lets hope we can somehow update the WLS 10.3.5 server with installed ‘Sherman Update 1’ 🙂

UPDATE May-10-2012:
Got this from support regarding upgrade of an existing WLS 10.3.5 server:

There was a confusion if could be installed on top of WLS as per the cerfification matrix is only certified for WLS

I got confirmation that ADF requires the Application Development Runtime libraries.
ADR can be installed on WLS 10.3.5 or WLS 10.3.6
So can be installed on top of WLS

UPDATE May-19-2012:

I got some more info about the possible upgrade path from Oracle I like to share:

Q1) Are the ADF ADF Runtimes certified against WLS 10.3.5?

Yes and we’ve updated the cert matrix to reflect this:

Q2) Is there a patchset to move from or to

No. As you’ve correctly identified, the only way is to install the Runtimes then apply the patch.

The release notes do highlight this fact, but do not mention that there isn’t a patch from to I’ll seek to get a clarification put in the release notes.

Q3) If is a patch on top of are all of the features available to

No. The patch overrides functionality in so customers should not assume this.

The answer to Q3) is probably the interesting one as it makes clear that even as we update from, we don’t get the features introduced with in JDev 😦
One other implication is that you can’t run applications from both versions on one WLS 10.3.6 server.

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 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 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,         
             FROM EMPLOYEES Employees 
             WHERE ( ( ( (UPPER(Employees.LAST_NAME) LIKE UPPER( :bindLN || '%') ) ) ) )
[105] Bind params for ViewObject: []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.

ADF: How to find out which ADF version is installed on a manged WebLogic server

As a developer and architect I’m working with different version of JDeveloper and WebLogic servers. Sometimes I switch version multiple times a day. Most customers have multiple deployment targets (development, QS and production) on different Weblogic servers. This make it sometimes hard to keep track of the different versions.

I searched for a way to find out which ADF Runtime is installed on a given WebLogic server. If you look at the console application or the Enterprise Manager application you’ll see no difference. Sometimes you can guess which version is running if you know which other application version is running under which server version. Still there should be a better solution.
Searching (my friend Google) the only way I found was to check the MANIFEST.MF of a specific jar on the server. As I don’t have access to a command shell on all servers this method won’t work for me. Then I stumbled upon the PrintVersion class ( which prints the BC4J version. A bit more digging led to the class oracle.jbo.Version which was mentioned in a really old blog entry from 2003 ( This class is still available and hold information about the ADF version like the build label and BC4J version. Some of the info is stored in static final variables and only one public method Version.getAsAtring() is available.

This class is the solution I was looking for. As I couöd not build an ADF application, but needed a solution which is deployable to a managed server, I decided to implement a web service which returns the BC4J version and the build label of the ADF Runtime Library deployed ton the WebLogic server.
To make this work, I could not directly access the static final fields of the Version class. Doing this would compile the version information from the ADF Runtime Library at compile time into the web service. To access the build label which has no getter method I need to use reflection. Finally I wrote this Class


import java.lang.reflect.Field;
import java.lang.reflect.Method;

import javax.jws.WebMethod;
import javax.jws.WebService;

import oracle.jbo.Version;

public class AdfVersion
    public AdfVersion()

    public String getVersion()
        return Version.getAsString();
    public String getBuildLabel()
        Class<?> cl = null;
            cl = this.getClass().getClassLoader().loadClass("oracle.jbo.Version");
        catch (ClassNotFoundException e)
            return e.getMessage();

        Method[] lDeclaredMethods = cl.getDeclaredMethods();
        Field[] lDeclaredFields = cl.getDeclaredFields();
            Field lDeclaredField = cl.getDeclaredField("buildLabel");
            String y = (String) lDeclaredField.get(lDeclaredField);
            return y;
        catch (IllegalAccessException e3)
            return e3.getMessage();
        catch (NoSuchFieldException e)
            return e.getMessage();

To make the web service independent from the Jdeveloper ADF Runtime I reference the ADF Runtime Library which is deployed on the server as shared library ‘’. For this I created a weblogic-application.xml descriptor and add the library ref to it.

<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-application xmlns:xsi=""

Now, after deployment of the EAR you can test the web service on different servers with different ADF Runtime Libraries deployed and see something like

WLS 10.3.5 with ADF Runtime Library

WLS 10.3.5 with ADF Runtime Library

WLS 10.3.5 + Sherman Patch and ADF Runtime

WLS 10.3.5 + Sherman Patch and ADF Runtime

The ear should be deployable on all 10.3.x WebLogic servers.

You can download the workspace (build with JDev from here: blogadfversoinws-zip.doc
Please rename the file to ‘.zip’ after downloading it! There in no DB connection needed.

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 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 10.3.2 10.3.3 10.3.4 10.3.5 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
Important Note: there are two releses of JDev 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. 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 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 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 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 for more info); running on WLS10.3.5 requires ADF 11.1.2.x patches onto Application Development Runtime 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 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 WLS 10.3.5+ can be used if no ADF is used in the application!
Running a standalone WLS12. needs a Oracle DB, Oracle DB or Oracle DB WLS 10.3.5+ can be used if no ADF is used in the application!
Running a standalone WLS12. needs a Oracle DB, Oracle DB or Oracle DB

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.

Follow up: Upgrading WLS 10.3.5 with ADF Runtime (Sherman Patch)

Since I published the article Upgrading WLS 10.3.5 with ADF Runtime (Sherman Patch) and filing a SR about the documentation error, Oracle has put up a note in MOS (Note 1328698.1 “How To Install the ADF Runtime Libraries 11g Release 2 ( in WebLogic Sever 10.3.5”) to clarify how to upgrade your WLS server.
In short you have to install two patches (12611176 and 12556632) before running the “upgradeADF(‘YOUR_DOMAIN_HOME’)” wlst command from ‘/oracle_common/common/bin/’.
Great, this could have saved my last weekend…

Upgrading WLS 10.3.5 with ADF Runtime (Sherman Patch)

A couple of weeks ago Oracle released JDeveloper with many new features we all waited for.
Great news … but wait, what to do with your running test, QS and production environment. As usual I assumed a new WLS to use with the new JDev. However, this time Oracle did not ship a new WLS but olny a patch (patch 12611176), which is only available if you have a valid support contract. This patch upgrades an existing WLS 10.3.5 with the new ADF Runtime
We are using Windows 7 64bit for our development PC and a Linux box for the WLS. Currently we are on jdev and WLS 10.3.4. The task to do is the upgrade to Here are the steps:

  1. update WLS 10.3.4 to WLS 10.3.5 (or do a fresh install if you like, doesn’t take more time). This is necessary as the patch requires WLS 10.3.5
  2. install ADF Runtime on the WLS 10.3.5
  3. check the WLS 10.3.5 installation using JDev, check if Enterprise Manager (EM) is running
  4. load patch 12611176 from mos and read the instructions how to apply the patch
  5. apply the patch
  6. test the patch installation using JDev, check if EM is running

This blog entry deals manly with the last two point in the list. The other points are documented well and it shouldn’t be a problem to do them.
After loading the patch and reading the instructions from the patch file, I installed the patch. This all was pretty straight forward, installation was OK.
After starting the WLS I noticed that the EM was not running. A look into the AdminSever log showed


A close look at the stacktrace shows a ClassNotFoundException. A search for the missing class reveals that it’s from the A JSF2.0 library

         Search for missing class

This clearly suggests that the new ADF runtime libs are not present in the WLS 10.3.5. Well, John Stegeman mentioned in a twitter entry that he too had the problem that the EM did not start after upgrading to and filed a SR for this (this resulted in Bug 12691349). At the time I testes this the bug was not jet published. So I tried many different ways to install the patch and get EM working which all resulted in the above stacktrace:

  • update WLS 10.3.4 to WLS 10.3.5; install ADF Runtime with EM installed; install patch
  • update WLS 10.3.4 to WLS 10.3.5; install ADF Runtime without EM installed; install patch; install EM
  • Fresh install of WLS 10.3.5; install ADF Runtime with EM installed; install patch
  • Fresh install of WLS 10.3.5; install ADF Runtime without EM installed; install patch; install EM

After rereading all available information about how to apply the patch again and the now available bug on MOS, I noticed one difference. The ‘README.TXT’ for the patch, after which I applied the patch, did not mention the need of executing a wlst command ‘upgradeADF’. The bug on MOS stated calling the ‘upgradeADF’ command as a possible cause of the bug.
The information about the command is only given in the ‘Release Notes for’ in the ‘Deployment’ section.

In the end I used the following method: fresh install of WLS 10.3.5; install ADF Runtime with EM installed; install patch
OK, so lets execute the ‘upgradeADF’ command. Here you have to be careful which wlst installation you use for the command.
The WLS server has it’s own wlst command interpreter installed at ‘$MW_HOME/wlserver_10.3/common/bin/’ whereas the patch installed a second on at ‘$MW_HOME/oracel_common/common/bin/’.
Using the first will throw errors like you see in the next picture:

         Error running wlst from false path

After running the wlst command ‘upgradeADF’ from the correct path ‘$MW_HOME/oracel_common/common/bin/’ and restarting all servers the result look like:

         Running WLS 10.3.5 with Sherman Patch

As you can see the EM is up and running. Note also that two JSF versions are running (1.2 and 2.0).

It looks like the bug John posted is dependent on the environment, as he uses a WIN 7 64bit installation whereas I’m using a Linux box. Still I would like Oracle to make clear in the patch documentation ‘README.TXT’ that you have to run ‘upgradeADF’ from the right location to get the patch installed properly.