JDeveloper: Looking for Samples or Best Practices on ADF?

Did you ever had the problem that you needed a sample for a specific problem, e.g. how to build a LOV or how to build a custom filter for a af:table? Or some in depth information about ADF?

If you can answer ‘No’, skip the rest of the post…

My guess is that everyone sometimes is looking for a sample. You know you have seen one on the web, but can’t remember exactly where.
Today, looking for a sample :), I stumbled upon this side: Oracle Application Development Framework Best Practices

I’ve been on this side a couple of times before, but never registered the

Search for Samples

Search for Samples

search field on the page. This is a very useful feature as it allows to search over many resources at one place, without the many useless hits you get by using standard web search. Just enter one ore more key world and search…

Bookmark this page!

JDeveloper 11.1.1.6.0 aka Fusion Middleware 11gR1 – Patch Set 5 is available: First Impression

Tweets, blogs articles are coming from all directions as the next ‘bug fix’ release of JDeveloper has gone public.

I’ll skip the download and install stuff for now, as there are some posts on this already. First thing I normally do is to read *all* documentation (just kidding). Well, I at least read the Release Notes and What’s New documents.

First thing which caught my eyes was the Deployment section. Here I find that JDev 11.1.1.6.0 internally uses a WebLogic Server of version 10.3.5. Still we need to set up an WLS 10.3.6 instance for testing as the next sentence states:

If you want to configure a WebLogic Server 10.3.6 domain to test an ADF application , you will need to install WebLogic Server 10.3.6 and use the 10.3.6 JRF template to add the ADF runtime libraries.

To verify this I installed JDev 11.1.1.6.0, deployed my ADF Version WebService onto the freshly build integrated WLS instance:

JDev 11.1.1.6.0 integrated WLS instance

JDev 11.1.1.6.0 integrated WLS instance

and here is the result of the ADF Version printout

ADF Version JDev 11.1.1.6.0 integrated WLS instance

ADF Version JDev 11.1.1.6.0 integrated WLS instance

This made me think about the convention that applications developed with JDev version 11.1.1.x should run on a WLS version 10.3.x, where x should be equal for JDev and WLS. This statement still is true (I guess) for all environments beside JDev development.

I’ll hope we don’t find a use case where this WLS version mismatch is the cause of error.

UPDATE:
Chris Muir blogged about this version mismatch between JDev and WLS here https://blogs.oracle.com/onesizedoesntfitall/entry/adf_runtimes_vs_wls_versions

JDeveloper: Way to show a Version Number in the UI

My last presentation at the German ADF Partner Community showed how to put a version number into an application ear and allows two versions of the same application to exist on a managed WebLogic Server. One question I got from the audience was how to show this version in the UI of the application. This blog post shows one way of doing this.
For those readers which do not know how to put a version number into an application EAR before deploying it to a WLS, lets start with this.
Andrejus Baranovskis has a blog post How to set EAR Version for ADF Application on WebLogic about this which uses a more hand coded approach. Edwin Biemond showed a small ant script to do is. I will show you a different solution using ANT.
This solution consists of a general GeneralVersionBuild.xml ANT script and a project dependent VersoinBild.xml ANT script which sets some properties (the version properties) for the GeneralVersionBuild.xml. The GeneralVersionBuild.xml defines the targets to alter the different version numbers you define for your applications and print out the version in the log like

Versioninfo:
     [echo] VERSION: V1.0.0.3 DB.V1 vom 2012/02/12 21:09
     [echo] Major: 1
     [echo] Minor: 0
     [echo] Fix: 0
     [echo] Build: 3
     [echo] Date: 2012/02/12 21:09
     [echo] DB-Schema Version: 1
     [echo] --------------------------------------------------------------------------------------------------

The information above is the complied from the version.properties file which defines the different parts of the version number:

#Build version info
#Sun Feb 12 16:06:18 CET 2012
DBSchema=1
majorVersion=1
fixVersion=0
minorVersion=1
buildDate=2012/02/12 16:06
buildNum=39

To manipulate the properties we use the targets defined in the GeneralVersionBuild.xml ANT script. This is called by the project dependent VersionBuild.xml ANT script:

<?xml version="1.0" encoding="UTF-8" ?>
<project name="AVIVersionBuild" default="make" basedir=".">
    <!-- # Relativ path to the base of the application -->
    <property name="root.dir" value=".."/>
    <property name="earFileBaseName" value="BlogAccessVersionInfo"/>
    <!-- PATH TO VERSION.PROPERTIES FILE (e.g.: src/de/hahn/blogxxxx/view/version.properties) -->
    <property name="file.version.properties" value="src/de/hahn/blog/accessversioninfo/view/version.properties"/>
    <property file="${file.version.properties}"/>
    <property name="deployFolder" value="../deploy/"/>
    <!-- PATH TO THE GENERAL VERSION BUILD ANT SCRIPT -->
    <import file="${root.dir}/Versionierung/GeneralVersionbuild.xml"/>
</project>

All we need to do is to set the Versionbuild.xml file as ANT”Project Buildfile” file

Setup Ant Project Buildfile

Setup Ant Project Buildfile

Now that the project has a version.properties file (at src/de/hahn/blog/accessversioninfo/view/version.properties) holding information about the current version of the application we need a way to access this information on a page in the UI. As we are using a property file we can bind this file as resource bundle into the project and access the parts (properties) with EL.
To add the version.properties file as resource bundle we open the project properties, select the “Resource Bundle” node and then set the properties from the bundle as outputText onto the page.

Make sure that you select the right project when you add a property file.

Add a property file as bundle

Add a property file as bundle


Next search for the version.properties file in the project
Select version.properties

Select version.properties


Now in the page we can access the property via EL. We drag an outputText component on the page and select its value from Resource bundle
Select a value from resource bundle

Select a value from resource bundle


Select value from property file

Select value from property file


This will create this entry in your page

<c:set var="aviviewcontrollerBundle"
   value="#{adfBundle['de.hahn.blog.accessversioninfo.view.version']}"/>

and here is the resulting outputText:

<af:outputText value="Version: #{aviviewcontrollerBundle.majorVersion}.#{aviviewcontrollerBundle.minorVersion}.#{aviviewcontrollerBundle.fixVersion}.#{aviviewcontrollerBundle.buildNum} from #{aviviewcontrollerBundle.buildDate}" id="ot6"/>

and the resulting page when you run the application

Running application

Running application

As you see the name of the resource bundle is set to “aviviewcontrollerBundle” (the default bundle name). This happens if you don”t already have a default bundle defined which contains a key value pair. You can rename it to e.g. “versioninfo” to make clear what the bundle is used for. In this case you have to change the EL to access to properties too.

    <c:set var="versioninfo"
 value="#{adfBundle['de.hahn.blog.accessversioninfo.view.version']}"/>
...
 <af:panelGroupLayout id="pgl2">
    <af:outputText value="Version: #{versioninfo.majorVersion}.#{versioninfo.minorVersion}.#{versioninfo.fixVersion}.#{versioninfo.buildNum} from #{versioninfo.buildDate}" id="ot6"/>
 </af:panelGroupLayout>
...

The sample workspace can be downloaded from here BlogAccessVersionInfo.zip. Please rename the file to ‘.zip’ after downloading it! It was build using JDeveloper 11.1.2.1 and uses the HR schema.

JDeveloper Gem: Debug Ant Scripts

I’m not sure if this feature of JDeveloper is widely known, but JDev allows you to debug ANT scripts as if they where java classes of a project.

I guess you normally don’t need to debug an ANT script, but sometimes it comes handy. A use case which comes up quite often lately is the installation for the FOD sample application. A couple of users have run into trouble running the MasterBuildScript from the FOD sample application. You can download the FOD sample from here.Be sure to load the FOD version for the JDeveloper version you are using.

After unzipping the demo you open the ‘Infrastructre’ work space from within JDev, open the ‘MasterBuildScript’ project and open the ‘Resources’ node. Here you find the ‘build.properties’ file which you need to adapt with your environmental settings.
Here is my sample build.properties file:

# Master Ant properties file for Fusion Order Demo
# All build files refer to this master list of properties
# Continuous builds override these settings
# $Id: build.properties 812 2007-02-20 07:14:33Z lmunsing $

# Base Directory for library lookup
jdeveloper.home=P:/jdeveloper
src.home=..//..


# JDBC info used to create Schema
jdbc.driver=oracle.jdbc.OracleDriver
jdbc.urlBase=jdbc:oracle:thin:@tdb02
jdbc.port=1521
jdbc.sid=ORCL

# Information about the default setup for the demo user.
db.adminUser=system
db.demoUser=FOD
db.demoUser.password=fusion
db.demoUser.tablespace=USERS
db.demoUser.tempTablespace=TEMP{code}

Now, to debug an ANT script, open the build.xml file in the MasterBuildScript project and search for the ‘init’ target. Here you set a break point as if this were a java source file.

'init' Taget

'init' Taget

Now right click the ‘build.xml’ file and select ‘Debug Ant Target…’ from the list. From the submenu you select the ‘buildAll’ traget.

Select Target to Debug

Select Target to Debug

You should quickly hit the break point set on the ‘init’ target. You can step over (F8) or step into (F7) like you can do with normal Java files. Best feature (which is the reason for the blog post) is that you can see and change the properties defined by the ANT script.

See and change ANT properties

See and change ANT properties

This should help you find bugs in ANT scripts and hopefully solve them too.

Chris Muir (in his comment) pointed to one more use case which should be mentioned. To get even more knowledge about the targets which are executed in an ANT script you can set more options. To get to the dialog you select ‘Advanced…’ from the list of targets

Select  'Advanced...' to get to more options

Select 'Advanced...' to get to more options


Then you select the target for which you want to set more options
Select target

Select target


and then go to the ‘Options’ step to set e.g. ‘Verbose’ output
Set 'Verbose' option

Set 'Verbose' option


When you finished the dialog the selected target starts running and produces this output
Verbose output

Verbose output


The interesting part is, that using the ‘Advances…’ target only sets the options for the one run or debug of the selected target. If you like to set one of the options permanently, you can do this in the ‘Manage Ant Settings…’ or the project settings
Permanent settings of options

Permanent settings of options

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 (http://docs.oracle.com/cd/E15051_01/apirefs.1111/e10653/oracle/jbo/common/PrintVersion.html) 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 (http://radio-weblogs.com/0123729/stories/2003/07/10/associationConsistencyOnNondetailVos.html). 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

package de.hahn.blog.adfversionws;

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

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

import oracle.jbo.Version;


@WebService
public class AdfVersion
{
    public AdfVersion()
    {
        super();
    }

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

        Method[] lDeclaredMethods = cl.getDeclaredMethods();
        Field[] lDeclaredFields = cl.getDeclaredFields();
        try
        {
            Field lDeclaredField = cl.getDeclaredField("buildLabel");
            String y = (String) lDeclaredField.get(lDeclaredField);
            return y;
        }
        catch (IllegalAccessException e3)
        {
            e3.printStackTrace();
            return e3.getMessage();
        }
        catch (NoSuchFieldException e)
        {
            e.printStackTrace();
            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 ‘adf.oracle.domain’. 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="http://www.w3.org/2001/XMLSchema-instance"
                      xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.1/weblogic-application.xsd"
                      xmlns="http://xmlns.oracle.com/weblogic/weblogic-application">
  <library-ref>
    <library-name>adf.oracle.domain</library-name>
  </library-ref>
</weblogic-application>

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 11.1.1.5.0 Runtime Library

WLS 10.3.5 with ADF 11.1.1.5.0 Runtime Library


or
WLS 10.3.5 + Sherman Patch and ADF Runtime 11.1.2.1.0

WLS 10.3.5 + Sherman Patch and ADF Runtime 11.1.2.1.0

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

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