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.

Handling images/files in ADF (Part 4)

This is a continuation of my already three part series about handling files and images in JDeveloper. The first three parts guided through the hole process:

    Part 1 gives an overview of the sample application I’m going to build and how to set it up
    Part 2 shows how to upload a file, store it and download it back to the client
    Part 3 implements two techniques to show the data (image) on the user interface
    Part 4 backport of the sample to JDeveloper 11gR1
    Part 5 implements a technique to show the uploaded file right after upload without the need to commit first

There is one missing part, which is that the whole sample was built using JDeveloper using JSF2.0 components. Running the sample in newer JDeveloper 11.1.2.x versions in no problem (tested up to However I got a couple of questions asking hoe to run it using JDeveloper 11.1.1.x version.
The shown techniques are all version independent, so that you can used them in your own application, but have to build your own UI.

I decided to backport the sample to run under 11.1.1.x too.

Part 4 Sample build to run with JDeveloper 11.1.1.x.

The sample can be downloaded from the ADF EMG Sample side

JDeveloper First Impressions

Oracle released a new version of JDeveloper Release 2 aka on May 2nd, 2013. Great news as the planned update of the OTN forums has been postponed for four weeks. Think about a new version and no forum to ask questions!

Well, a look into the release notes reveals that there is not much new in this version beside a new version on the ADF Mobile development framework (1.1). This update gets us push notifications, file content display (Android), badging API support (iOS only), application archive support and infrastructure updates. These are performance enhancements, iPhone5 and iPad mini form factors support (needed for the iStore), migration of PhoneGap 1.0 to Cordova 2.2 and updated Xcode and Android SDK support.
I have not tested the new mobile stuff as I’m currently busy with other urgent stuff. Let’s take a close look to the new features of the version beside the mobile update:
Start of List

End of List
Yes there is no official new feature in this version, only bug fixes. However, the list of bug fixes can’t be found by clicking the link in the release notes, Somehow the link does not work (at least not for me). To find the list of fixed bugs click on the link for the bug fixes and scroll up a couple of pages.
Most fixes are for mobile, a couple of the fixes are for IE. Check the whole list at JDeveloper 11g Release 2 (
The JDK 1.7.0 bug (see issue ADFEMG-120). The backport did not make it into the version!
So you still have to run this version on a JDK 1.6.0. Be sure to install an JDK 1.6.0_35 or higher as you otherwise get an error

“Java version 1.6.0_24 not supported. The minimum version required is 1.6.0_35.”

For more information about this refer to this thread on the (still old) OTN forum.

To install the new ADF Runtime for a standalone WebLogic Server you need two patches which are only available via Oracle support. The patch numbers are 16273810 (ADF) and 16156149 (WebCenter). Both patches need to be applied. For detailed information on how to apply the patches read the release notes.

UPDATE 13-05-2013
Chris Muir pointed out that the issue with the bundeld JDK 1.6.0_24 has been fixed in the meantime.
Apparently I missed this information as it’s not made overly public. I knew Oracles worked on a fix for the JDK problem, but just adding a ‘.1’ to the build number,which is build 6436.1 now, did not get my attention. Checking the documentation did not reveal much more. First hint I found in the release notes:

Oracle JDeveloper and Application Development Framework 11g Release 2 ( is a minor update to For a list of new features in 11g Release 2, and specific customer bugs fixed in the update release see the What’s New document on OTN.

Note the versions mentioned? I’m not sure this is by intention, but further searching the release notes I found the info under the ‘Installation’ topic. It may help to add this info on the front page of the documentation.

OTN Forum Update posponed to June 2013

Oracle just announced that the planned update of the OTN forums to a new modern version has been posponed to June 2013.


UPDATE – launch delayed for four weeks, into June. 

In a last minute decision we have delayed launch so that we can establish thread level redirects across the site.  I am very happy with this outcome and expect a much smoother transition when we do make the switch.

Good move!  Better wait until all links can be migrated than update and many links are broken.

Bye, Bye Good Old OTN Forums

Starting May 3rd 2013 the good old OTN forum software get it’s desperately needed live-cell therapy. Only a few people know how the new forum software looks like and how it works (I’m none of them).

A couple of things are already known, e.g. some new terminology (spaces instead of forum), more colorful or modern (so better targeted for the facebook generation?), we hopefully get a search which really searches what we are looking for and performance should be better too. You can read for yourself on this OTN thread.

There are some things which are not clear to me, like how all the links posted in threads are handled. From the discussion in the thread above we learn that hopefully all links are migrated. Well, this reminds me when Oracle reorganized its websites. Nothing was reachable any more. There are still link which are broken, forcing us to dig deep in the WWW to get the information back. So let’s hope this will work this time.
However, this adds a lot of work to all the links which are stored in blogs and wikis pointing to interesting information in OTN threads. I’ll lose about 30% of my personal knowledge store and have to update some links here in this blog too.

I don’t want to start a new discussion about the dammed reward system (yes, the points are meant), as they do not alter the system at the moment. Interesting is that there are plans to get real-world rewards at some point in the future (do I get rich?:)).

For sentimental reasons I put a couple of screenshots of the old look and feel in this blog. In a couple of month or years, when dust has settled, we can look back at them and decide if the live-cell therapy has rescued the patient.