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.

Pimp up an af:query to show the result table in an af:panelCollection

A user on the JDev Forum asked an interesting question on how to show the result of an af:query (e.g. dropped as ‘Query Panel with Table’).
A quick check showed that dropping a named criteria as ‘Query Panel with Table’ produces af:panelGroupLayout containing a af:panelHeader for the af:query component and an af:table for the result of the query.
Here is a sample of a drop as ‘Query Panel with Table’ (some details are omitted to save space):

                    <af:panelGroupLayout layout="vertical" id="pgl1">
                        <af:panelHeader text="Employees" id="ph1">
                            <af:query id="qryId1" headerText="Search" disclosed="true"...
                        <af:table id="resId1" value="#{bindings.EmployeesView1.collectionModel}" var="row"
                                  rows="#{bindings.EmployeesView1.rangeSize}" ...>
                            <af:column ...>
                            <af:column ...>

The user asked for functionality like hiding columns or detachment of the table to get a full screen mode. In short he wanted to use the functions of a af:panelCollection together with the automatic setup of af:query and the result table.

This can easily be done by surrounding the af:table component by a af:panelCollection and rewiring the ‘resultComponentId’ property of the af:query, as the af:panelCollection is a naming container.
In JDev select the table with a right click and select ‘Surround with…’

Surround Table with panel collection

and search for the ‘Panel Collection’

Select 'Panel Collection'

and click ‘OK’ to finish this step.
Now we need to change the ‘resultComponentId’ property of the af:query component to account for new the naming container which is added through the af:panelCollection component.
Select the af:query in the design view or in the structure window and open the property inspectors common tab

Change af:query
As you can see JDev shows an error for the ‘resultComponentId’ property as the target has changes its naming container. To change it click the small arrow down at the right hand side of the property, select ‘Edit…’. In the next Dialog look for the af:table component inside the af:panelCollection and select it. Click ‘OK’ to finish the change.
the resulting code looks like (some details are omitted to save space):

                    <af:panelGroupLayout layout="vertical" id="pgl1">
                        <af:panelHeader text="Employees" id="ph1">
                            <af:query id="qryId1" headerText="Search" disclosed="true"
                        <af:panelCollection id="pc1">
                            <f:facet name="menus"/>
                            <f:facet name="toolbar"/>
                            <f:facet name="statusbar"/>
                            <af:table value="#{bindings.EmployeesView1.collectionModel}" var="row"
                                      rowSelection="single" id="resId1">
                                <af:column sortProperty="#{}"
                                <af:column sortProperty="#{}"

When you run the code you are able to detach the table and hide columns

Resulting page

Get the start URL of your Web Application the easy way in JDev

WOW, as always Oracle surprises me (and hopefully many other users) with a new version of JDeveloper, this time in short succession of the latest version.

It got me right in the middle of a short vacation, so I could only read some news and blogs via my smart phone. Back home I tarted to take a closer look on the new JDev
Like many other users I can say: Impressive!
I like fast loading of JDev itself and the faster embedded WLS startup time best (so far, as I’m still checking out other new features).

One new feature which caught my eyes is that you can easily get the starting URL of your web application without scrolling and searching the WLS log output. You simply select the ‘Actions’ drop down box in log output window and select ‘Show Target URLs’ to get the starting URL you specified.

Show Target URL action

Show Target URL action

and your get
Start URL in Log window

Start URL in Log window

This is one feature I never asked for but will use it pretty often.

Dump VO query and it’s parameter with their values

Based on a request on JDeveloper and ADF forum I wrote a small method to dump the query of a VO together with it’s bind variables (autom. inserted by the framework and user defined) and their values.
The method below gets the query in it’s actual state, checks the variables and dumps their names and values. I’m using a simple ‘System.out.println’ to dump the information for simplicity. If you like to use the method in a more general way (e.g. in a base class) I would recommend to use a ADFLogger. See Duncan Mills bloghere

    public void dumpQueryAndParameters()
        // get the query in it's current state
        String lQuery = getQuery();
        //get Valriables
        VariableValueManager lEnsureVariableManager = ensureVariableManager();
        Variable[] lVariables = lEnsureVariableManager.getVariables();
        int lCount = lEnsureVariableManager.getVariableCount();
        // Dump query
        System.out.println("---query--- " + lQuery);
        // if variables found dump them
        if (lCount > 0)
            for (int ii = 0; ii < lCount; ii++)
                Object lObject = lEnsureVariableManager.getVariableValue(lVariables[ii]);
                System.out.println("  --- Name: " + lVariables[ii].getName() + " Value: " +
                                   (lObject != null ?  lObject.toString() : "null"));

You can overwrite the executeQuery() method of the ViewObjectImpl class and call the method above like

    public void executeQuery()

Executing a Query you should see output like

---query--- 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 ( ( (Employees.LAST_NAME LIKE ( :vc_temp_1 || '%') ) ) )
  --- Name: vc_temp_1 Value: gr%
  --- Name: bindHireDate Value: null

The nice part of this method is that it dumps user defined bind variables as well as automatically added variables by the framework. In the output above vc_temp_1 is a variable of a filter entered in an af:table component.

Creating a JAR File in JDeveloper

A question on the OTN JDev forum asked how to build a jar and include all dependent libraries into the jar.
Well you can argument that ‘all’ dependent libraries are way too much and that only libraries not already available on the target should go into the jar, but this it up to the developer.
To create an archive you select the ‘Depolyment’ section in the project or application (for EAR archives) properties and click the ‘New’ button.
First declare which type of archive (JAR, WAR, EAR, ADFLIB …) you like to build. In the case described here we select ‘JAR File’ and choose name like MyJar

After clicking OK we see the default dialog to create an archive.
The part we are interested in is the ‘Library Dependencies’ which show all the libraries (which contain the actual jars) the project need to compile and run. Users might get confused with this section, as it does not put the selected jars into the archive, but is only the list of jars needed to compile or run the project.
To really add the jars to the archive you need to create a new ‘File Group’ of type ‘Libraries’

Select the location in the archive you like to put the jars (e.g. libs) and select the ‘Contributors’

where you select the libraries which should be packed into the archive. As you see there are some libraries with gray check marks. These are the libraries which are marked as ‘Deploy by default’ in the library definition. Here you can select some or all of the other libraries you like.
You can edit the ‘Deploy by default’ for your own libraries in the ‘Manage Libraries’ dialog

Now when you deploy the profile you get a jar containing the selected jars from the libraries.