JDev 12.2.1.3: Creating a shared skin jar (Part 2)

In part 1 or the series we created a simple skin, built an ADF-Library from it and tried to reuse it by deploying it to a WebLogic Server. This approach failed. In this part, we try another option to share a jar with

Sharing the skin with other applications

To share the skin with other application we can

1. Create an ADF Library
   1. Add this library to the other application
   2. Add this library as a shared library to a WebLogic Server
2. Create a normal jar
   1. Add this library to the other application
   2. Add this library as a shared library to a WebLogic Server

For this blog the way we want to use if 2b. This allows to create the skin once, deploy it to a server and use it in every other application. In the next paragraph, we try out option 1a to show the problems when reading resources from a jar file.

Using a shared skin

Option 2b

Here we create a jar file containing the skin and additional resources like images and deploy it directly to a WebLogic Server as a shared library. The advantage is, that other applications can use the skin and other resources directly and that the jar can be versioned to allow different versions of the same jar on the server.

Option 1a which we discussed in the previous chapter doesn’t work for images. However, the documentation ‘Deploying a Custom Skin File in a JAR File’ and Frank Nimphius pointed it out in e.g. 86. Reading boilerplate images and icons from a JAR or How-to share skin definition files across applications how the jar file must be structured to allow the resource servlet to read the resources. The essential sentence is

‘All image resources and CSS files must also be under the META-INF directory.’

In his article, Frank suggested using the command line jar tool to create the jar. I show how to use JDev to create the jar with the needed structure and how to deploy it to a server as a shared library.

A sample application is used to use the skin and to show an image load from the jar.

The building plan for a skin in a shared Library which can be deployed to a WebLogic server is given in the article as:

To implement the shared library approach, developers need to change their existing skin definition so it can be deployed in a JAR file. The steps for this include

– Creating a META-INF directory – Creating a trinidad-skins.xml file that defines the skins deployed with the JAR file

– Creating an META-INF/adf sub directory for images and icons served from the JAR file

– Changing the image reference in the CSS to include the “adf” directory, which makes sure images and icons are handled by the ADF Faces resource loader, which can read resources from JAR files

– JAR the META-INF directory to create the library file

Looking at the current project for the skin we see a different layout

In the article Frank instructed to create the needed folders yourself and copying or moving the files to the new structure, then to use the command line to build a jar from the structure.

I’ll show how this can be done with a special deployment descriptor from within the project. The image below shows the needed layout of the final jar file.

To transform the folder structure present in JDev to the needed structure of the final jar, we create a new deployment descriptor in JDev

In image 4 we see the first part of the solution: here we set the path inside the jar to ‘MEAT-INF’. This will guarantee the structure we need. Then we add another contributor to the list (public_html) to get everything we need into this folder. Then we use the ‘Filters’ node to select all content we need skin part

Next part is to create another path in the jar for the metadata of the skin

We add another file group for the resources

Now we can deploy the jar using the new deployment descriptor

And the jar file is created in the deploy folder. It holds all files in the right folders

Finally, we can deploy this jar to the WebLogicServer. In this case, I use the integrated WLS, but it can be any stand-alone WLS too.

The error message you see on the 7th image can be ignored. It only tells you that the library can’t be deployed as an application but only as a shared library. This is exactly what we want to do 🙂

Now the jar file is deployed on the WLS as a shared library and can be used for every application on this server.

We use the existing application from part one to consume the jar skin from the shared library and show the images deployed with the jar.

Before we go any further, we have to remove the ADF Library we added to show the problem from the project. For this open the project properties and select the ‘Library/Classpath’ node and remove the ‘ADFLibrary’ entry

The page should now look like no skin is used at all.

As we already added a skin (with the ADF Library) we don’t have to do this again. However, we have to add a library reference to configure the application to use the shared library deployed on the server. For this, we open the application descriptors and edit the ‘weblogic-application.xml’ file by double clicking the entry in the application resources section

In the ‘Shared Library Reference’ section, we add a reference to the now deployed shared jar ‘blogsharedskin’

Saving everything we don’t see any change to the page design, as the library isn’t part of the application yet. Starting the application we get

Just what we liked to see. The images are visible, checking the page with Chrome’s Dev Tools shows that the images are correctly loaded

This proves that the shared library with the skin and the images are working correctly.

To make the skin visible in JDev during development, we can add the jar we developed to the server a library. We create a library

and make sure the ‘Deploy by default’ is NOT set. Adding the library to the project

will make the skin visible in design mode

The unset checkmark prevents the jar from being packed into the WAR or EAR file. It’s just used in the IDE. That you can’t see the images is normal as there is no full server to serve the images to the design view.

Summary

In this mini-series, I showed the problem when creating a skin as ADF Library and trying to share it on a Weblogic Server. Then I showed how to create a deployment descriptor for the skin and other resources and how to deploy the resulting jar to a WebLogic Server.

The sample application can be downloaded from BlogSharedSkin. The sample was created by using JDev 12.2.1.3 but the same technique can be used in any 12.2.1.x JDev version. There is no database connection needed.

JDev 12.2.1.3: Creating a shared skin jar (Part 1)

In earlier versions of JDev, skins have been created either by pure code or by using the free Skin Editor. However, since JDev 12.2.1.x the skin editor has been integrated into JDeveloper itself.

A couple of questions in the ODC JDeveloper space are about how to create a skin with JDev which can be deployed as a shared library to a WebLogic Server. I gave this a try and it turned out, that you can build an ADF library jar from a skin project but you can’t use images to this jar which you might want to use in the application.

In this blog, I’ll show how to create a skin with resources like images and how to build a jar file from the skin together with the images and deploy it aa s shared jar to a WeblogicServer.

Building a skin project

The first part is to build a small skin project. The project we use to create a minimal skin, just to show that the skin is changing something. Then we add some images to the skin which we want to use in the application which uses the skin. Such images can e.g. used on an af:button component.

We start by creating a new application as an ‘ADF Fusion Web Application’

As we don’t need the created model project we delete it completely

If you get another dialog, telling you that you can’t undo the action, answer ‘Yes’ to delete the project. Now you should see a workspace with just the one project:

Know that we have a project we add a skin and e.g. add some skin selectors to change to the color of the button text. For this, we right click the ‘Web Content’ folder in the project and select ‘New from Garaly’ and then select ‘ADF Skin’ from the ‘JSF/Facelets’ node and fill in the basic information:

This will create the needed css file and the descriptors which define our skin (trinidad-config.xml and trinidad-skins.xml).

We open the sharedskin.css file if it’s not open already and switch to source mode. Here we add two simple skin selectors

which are changing the color of the text of a button and a link. You can add more sophisticated selectors but for this blog, it’s enough to show the working skin. To make it more interesting, and because that’s the real reason for this blog, we add some images to the skin which we like to use in the application using the skin. We add the images into a new folder like shown below

The reason for this structure is, that to read the images from the jar in the consuming application, we need a special resource loader. In case of ADF it’s the resource servlet which listens to the URL pattern ‘/adf/’’. This servlet is installed automatically for ADF Web Applications and is configured in the web.xml file

The final task for the skin project is to create a jar file which we can use in other applications. The easiest way to get such a jar is to create an ADF Library deployment descriptor. Open the project properties of the skin project and select the ‘Deployment’ node

And click the ‘New Profile’ icon, select to create an ADF Library Jar

and click ‘OK’. The remaining dialogs you can just click ‘OK’ or ‘Finish’.

To create the library we have to execute the descriptor by right-clicking on the project and selecting ‘Deploy’ and choosing the ‘sharedskinadflib’

This will create the jar in the ‘deploy’ folder of the project.

Sharing the skin with other applications

To share the skin with other application we can

1. Create an ADF Library
   1. Add this library to the other application
   2. Add this library as a shared library to a WebLogic Server
2. Create a normal jar
   1. Add this library to the other application
   2. Add this library as a shared library to a WebLogic Server

For this blog, we want to use option 2b. This allows to create the skin once, deploy it to a server and use it in every other application. In the next paragraph, we try out option 1a to show the problems when reading resources from a jar file.

Using a shared skin

Option 1a

We start with option 1a, just to show the problem when we try to read a resource from a jar. We build another ADF Fusion Web application and add the skin as ADF library from a ‘File System Connection’ which we create and let it point to the ‘deploy’ folder

Right-click on the ‘sharedskinadflib’ and add it to the new sample project. This will make the skin available to the application. To use the skin we have to add a skin to the application like we did to create the skin project. The difference is that we now choose the shared skin as the base skin

Creating a new page and adding a button and/or a link to the page we see the new style introduced by the ‘sharedskin’

So, the shared skin is working. Well, yes, but what about the images we added to the ‘sharedskin’?

Let’s try to add one to the button. In the property editor, we select the icon property of the button and click ‘Edit’ to get

However, we don’t see any image in the whole project. As we know where we put the images (or we can look into the sharedskinadflib) we can just add the path to the image like ‘skins/sharedskin/adf/images/home.png’ and we see the image

Running the application we get the page with the button but don’t see the image

Using DeveloperTools we see that the resource couldn’t be found. Inspecting the button element we see

The path to the image is not found 😦

If we change the address of the image to ‘/adf/images/home.png’ to use the resource servlet we still get an error

The reason is that the resource servlet expects the resources in a different path inside the jar. Every resource which should be read from a jar should be in a folder named ‘META-INF’.

The ADF library did not put the images into the META-INF folder

The problem is that we can’t change the layout of the ADF Library. When you create an ADF Library there is no option to make any changes to the content of the jar.

The conclusion is that using a skin in an ADF Library is problematic if there are other resources which you need to share.

To be continued…

In the final part 2 of the series, we see how the skin can be shared with other applications.

Enable Oracle JCS to access External REST API

For a training I’m preparing I had to implement a POC on how to access an external REST API and to make it available in an ADF application running in the Oracle Java Could Service.

This task sounds pretty easy, nevertheless it’s best to see this working before starting a training which in the end will not work.

I decided to use Spotify public available REST API at https://api.spotify.com for this task. I started by creating a simple Fusion Web Application using JDev version 12.2.1.2.0. To this project I added a custom model Project which I later used to add the REST DataControl pointing to the Spotify track search API.

As this post isn’t about how to create such a project and use it in your normal ADF application, I spare the details here and write this up in another blog post.

Implementing a REST DataControl is pretty straight forward and the sample application was set up quickly. The first problem you might run into, even on the local development machine is this

error you get when you try to access the public API from inside the WebLogicServer. To make this error searchable for other users here is a part of the stack trace

javax.net.ssl.SSLKeyException: Hostname verification failed: HostnameVerifier=weblogic.security.utils.SSLWLSHostnameVerifier, hostname=api.spotify.com.
at weblogic.security.SSL.jsseadapter.JaSSLEngine.doPostHandshake(JaSSLEngine.java:686)
at weblogic.security.SSL.jsseadapter.JaSSLEngine.doAction(JaSSLEngine.java:757)
at weblogic.security.SSL.jsseadapter.JaSSLEngine.unwrap(JaSSLEngine.java:133)
at weblogic.socket.JSSEFilterImpl.unwrap(JSSEFilterImpl.java:644)
at weblogic.socket.JSSEFilterImpl.unwrapAndHandleResults(JSSEFilterImpl.java:541)
at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:99)
at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:78)
at weblogic.socket.JSSESocket.startHandshake(JSSESocket.java:240)
at weblogic.net.http.HttpsClient.New(HttpsClient.java:574)
at weblogic.net.http.HttpsClient.New(HttpsClient.java:545)
at weblogic.net.http.HttpsURLConnection.connect(HttpsURLConnection.java:236)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:685)
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:41)
at weblogic.net.http.HttpURLConnection.getResponseCode(HttpURLConnection.java:1545)
...

This problem can easily sorted out by changing the ‘Hostname Verification’ to custom and to specify ‘weblogic.security.utils.SSLWLSWildcardHostnameVerifier’ as ‘Custom Hostname Verifier’. Here are the detailed steps:

1. Go to the WebLogic admin console -> Environment -> Servers -> Server -> Configuration -> SSL
2. Under advanced options , change “Hostname Verification” from “BEA Hostname Verifier” to “Custom Hostname Verifier”.
3. Set “Custom Hostname Verifier” to weblogic.security.utils.SSLWLSWildcardHostnameVerifier
4. Click “Save” and then “Activate Changes”
5. Restart your server.

After this the sample application will run on the local development machine or an stand alone webLogic Server.

Now the fun part begins, making the application run in the Oracle JCS. Here I started with setting up a new Java Cloud Service with a WebLogic Server of version 12.2.1.2 and deployed my local running application to this new JCS.

The application did start OK, but when I came to the point where the application tried to call the external REST API all I got is: NOTHING

I only saw a spinning cursor, no error message on the UI regardless of my exception handler. It turned out, that I did not wait long enough for the error message to come up. The REST call timed out eventually providing more info in the servers log file

Exception in invoking HTTP method GET from Rest data control. Cause: javax.ws.rs.ProcessingException: java.net.ConnectException: Tried all: 3 addresses, but could not connect over HTTPS to server: api.spotify.com port: 443

It looks like the external REST call is not allowed. Here is the REST call

https://api.spotify.com/v1/search?q=sorry&type=track

If you write this into your browser you’ll get a JSON string in return, something like

{
 "tracks" : {
 "href" : "https://api.spotify.com/v1/search?query=sorry&type=track&offset=0&limit=20",
 "items" : [ {
 "album" : {
 "album_type" : "album",
 "artists" : [ {
 "external_urls" : {
 "spotify" : "https://open.spotify.com/artist/1uNFoZAHBGtllmz…

telling me that the problem is somewhere with the JCS. I ask for help in the OTN Java Cloud Service space and got an answer that there must be a rule missing. This is true to some point as I tried to access the REST API with curl from the JCS command shell

which did not work either. The interesting part is that you can do the same from the DBCS command shell and get the right answer.

I tried to add a rule to allow the access but looking at the possible source and destinations lists this did not work. Only

• OTD — The Oracle Traffic Director load balancer VMs
• WLS_ADMIN_SERVER — The WebLogic Server Administration Server VM
• WLS_MANAGED_SERVER — The WebLogic Server Managed Server VMs

are allowed as destinations and my rule should allow the managed server (source) to access the PUBLIC_INTERNET or allow access to https protocol port 443.

After some more reading and testing I found a solution, however I’m not sure if this is the best way to handle this. Anyway, for others users who run into the same problem here it is:

First you have to create a ‘Security List’ Which you name e.g. outbound_wlsms_https_traffic which denies incoming packages and allows outgoing packages

Next a ‘Security Rule’ can be created like

with source set as the managed server and destination the new security list. After that the access to the external REST API works.

JDeveloper 11.1.2.3.0 is out together with Oracle ADF Essentials

Today Oracle released the next (minor) JDeveloper release 11.1.2.3.0. The big news about this is the first release of Oracle ADF Essentials. ADF Essentials combines the core ADF technologies in a bundle free to use (it comes on its own web page, see link!)

Oracle ADF Essentials is an end-to-end Java EE framework that simplifies application development by providing out-of-the-box infrastructure services and a visual and declarative development experience. Oracle ADF Essentials is free to develop and deploy.

ADF Essential comes with it’s own FAQ which answers questions like ‘Is it really free?’ and ‘What’s in the package’. Take a look at the FAQ for all the questions and answers!
To give a summary of the included and excluded technologies read the quote from the FAQ:

What is included in Oracle ADF Essentials?
Oracle ADF Essentials includes the following Oracle ADF
components: Oracle ADF Faces Rich Client Components,
Oracle ADF Controller, Oracle ADF Model and Oracle ADF
Business Components.
The following functionality is not included in Oracle ADF
Essentials, and requires the full Oracle ADF version – Oracle
ADF Mobile, Oracle ADF Desktop Integration, Oracle ADF
Security, The Oracle ADF Web service data control, Oracle
ADF remote taskflows, Oracle ADF Business Component’s
Service Interfaces, Oracle ADF Data Controls for BI, Essbase
and BAM, Integration with Oracle Fusion Middleware features
such as MDS, OPSS, OWSM, Enterprise Manager and
MBeans, High Availability and Clustering.

That’s almost all I ever use on a daily basis. One of the features the community was looking far is the ability to deploy to GlassFish 3.1 and and other server you like without buying a licence. Let’s see how the community handles all this.

Beside the news on the ADF Essentials I had a short look at JDev 11.1.2.3.0. There are mostly bug fixes in this version. The new mobile is missing (hopefully we get it with 11.1.1.7.0). Some nasty bugs (e.g. task-flow initialization) are fixed. See the Release Notes for the full list of bug fixes. At the time of writing this the Release Nostes where not available (!?), hopefully the missing patch numbers needed to upgrade a WLS 10.3.6 server are added when the document is back on.
Other then the possibility to deploy to GlassFish 3.1 there are only a couple of changed and new features in the DVT department. Notable is the change of the af:table rendering on tablet devices: pagination is back!

First impression was that this version starts even faster then the 11.1.2.2.0 version. The reason might be that more features are only loaded when you use them the first time (OSGI), but I couldn’t find out if this is the case. Nevertheless, faster starting (my personal impression) is welcome!

Lets see when we get the patch numbers to upgrade an existing WLS. I’ll then update my other blog post JDeveloper Versions vs. Weblogic Server Versions

25th-Sep-2012 Update: The patch numbers are now available in the Release Notes:

For 11.1.2.3.0, the patch numbers are 14582286 (ADF) and 14582309 (WebCenter). Both patches need to be applied. Download the patches from My Oracle Support and follow the instructions to apply the patches.

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

and here is the result of the ADF Version printout

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

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

Next search for the version.properties file in the project

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 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

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.

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

or

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.

WLS 10.3.x: Deployment faild with ‘Invalid Archive’

I run into a strange problem today while working an a presentation about a ‘One Click Build’ process. Part of the presentation is building an EAR archive which can be deployed to a WLS server (10.3.5 + Sherman + update2) running under Ubuntu Linux 11.04. The application is build with JDev 11.1.2.1.0. First time I build the EAR and deployed it to my test server all went OK.
I added some files to my project rebuild the ear and got the following

Error dialog

A look into the log revealed nothing to shed light on this error

Error Log

For all searching for this exception I include the stack trace as text here too:

java.io.IOException: Exception in AppMerge flows' progression
at weblogic.deploy.api.internal.utils.AppMerger.getMergedApp(AppMerger.java:70)
at weblogic.deploy.api.model.internal.WebLogicDeployableObjectFactoryImpl.createDeployableObject(WebLogicDeployableObjectFactoryImpl.java:181)
at weblogic.deploy.api.model.internal.WebLogicDeployableObjectFactoryImpl.createDeployableObject(WebLogicDeployableObjectFactoryImpl.java:163)
at weblogic.deploy.api.tools.SessionHelper.initialize(SessionHelper.java:727)
at weblogic.deploy.api.tools.SessionHelper.initializeConfiguration(SessionHelper.java:556)
at weblogic.deploy.api.tools.SessionHelper.initializeConfiguration(SessionHelper.java:544)
at oracle.sysman.emas.sdk.picFramework.deploy.WLSDPConfigTreeManager._initialize(WLSDPConfigTreeManager.java:165)
at oracle.sysman.emas.sdk.picFramework.deploy.DPConfigTreeManager.<init>(DPConfigTreeManager.java:201)
at oracle.sysman.emas.sdk.picFramework.deploy.WLSDPConfigTreeManager.<init>(WLSDPConfigTreeManager.java:108)
at oracle.sysman.emas.sdk.picFramework.deploy.WLSDeployer._buildDPDeployConfigTree(WLSDeployer.java:741)
at oracle.sysman.emas.sdk.picFramework.deploy.WLSDeployer.buildup(WLSDeployer.java:471)
at oracle.sysman.emas.model.oc4j.deploy.DeployModelBase.buildup(DeployModelBase.java:876)
at oracle.sysman.emas.view.oc4j.deploy.DeployWizardSelectArchiveViewBean.goLoadArchive(DeployWizardSelectArchiveViewBean.java:1561)
at oracle.sysman.emas.view.oc4j.deploy.DeployWizardSelectArchiveViewBean.processCurrentStepAction(DeployWizardSelectArchiveViewBean.java:2287)
at oracle.sysman.emas.view.oc4j.deploy.DeployWizardTrainViewBean.doNext(DeployWizardTrainViewBean.java:441)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.el.parser.AstValue.invoke(Unknown Source)
at com.sun.el.MethodExpressionImpl.invoke(Unknown Source)
at org.apache.myfaces.trinidad.component.MethodExpressionMethodBinding.invoke(MethodExpressionMethodBinding.java:46)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at org.apache.myfaces.trinidad.component.UIXCommand.broadcast(UIXCommand.java:190)
at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent$1.run(ContextSwitchingComponent.java:130)
at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent._processPhase(ContextSwitchingComponent.java:461)
at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent.broadcast(ContextSwitchingComponent.java:134)
at oracle.adf.view.rich.component.fragment.UIXInclude.broadcast(UIXInclude.java:112)
at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent$1.run(ContextSwitchingComponent.java:130)
at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent._processPhase(ContextSwitchingComponent.java:461)
at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent.broadcast(ContextSwitchingComponent.java:134)
at oracle.adf.view.rich.component.fragment.UIXInclude.broadcast(UIXInclude.java:106)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:787)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1252)
at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._invokeApplication(LifecycleImpl.java:965)
at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:346)
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.help.web.rich.OHWFilter.doFilter(Unknown Source)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.sysman.emSDK.license.LicenseFilter.doFilter(LicenseFilter.java:101)
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 oracle.sysman.emas.fwk.MASConnectionFilter.doFilter(MASConnectionFilter.java:41)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:180)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.sysman.eml.app.AuditServletFilter.doFilter(AuditServletFilter.java:179)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.sysman.eml.app.EMRepLoginFilter.doFilter(EMRepLoginFilter.java:203)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.sysman.core.model.targetauth.EMLangPrefFilter.doFilter(EMLangPrefFilter.java:158)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.sysman.core.app.perf.PerfFilter.doFilter(PerfFilter.java:141)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.sysman.eml.app.ContextInitFilter.doFilter(ContextInitFilter.java:542)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
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)
Caused by: weblogic.utils.compiler.ToolFailureException: Exception in AppMerge flows' progression
at weblogic.application.compiler.AppMerge.merge(AppMerge.java:172)
at weblogic.deploy.api.internal.utils.AppMerger.merge(AppMerger.java:88)

The other log files available didn’t help either. So started to remove the files I added after the last successful deployment. I tagged this version, so I new where to start. In the end I found the file:
Einführung.pdf
As you see the file contains a German special character ‘ü’. It turned out that an EAR file should not contain files with special characters in their name. I did not test this on a WLS running under Window, as I don’t have one installed, but I guess it’s working there as I did not get this error running the application on the integrated WLS under a WIN 7 64Bit system.

ADFLogger: Using a Custom Formatter Class to Print Log Messages

Based on some posts on the OTN JDeveloper forum this article shows how to implement a custom fdormatter class to use with ADFLogging and how to integrate it with the embedded WLS instance in JDeveloper. Sample workspace for the custom logger is available at the end of the article.
For this post I assume you now your way around java.util.logging. I show how to implement a custom formatter class to format the log messages with more information and a different style. The picture below shows the general java logging model:

General Logging Model

As the model shows the formatter is used by the log handler which gets a log record and processes it by piping the record through a filter and then through a formatter to finaly pass it to the attached output target. In most cases the output target is a file, a db table, a system log or a stream. For the console logger its most often a stream (e.g. stdout and/or stderr).

A typlical JDev log message from the ConsoleFormatter looks like this:

<AdfcAppInitializer> <loadDebugFacades> ADFc: Initializing ADF Debugger

I’ll change this to:

FINE: 22.09.2011 13:18:17 - de.hahn.blog.popupregion.backingbeans.pageflow.SelectionBean$beaVersion0_39.selectionListenerEmp(SelectionBean.java:92) - 15 - de.hahn.blog.popupregion.backingbeans.pageflow.SelectionBean
  Selected: oracle.jbo.Key[105 ]

The general layout of the log message is

data in [] is customizable, data in {} is printed only if available
level: date time [- threadId] [- class] [- method] [- message] {- throwable.message}
These parameters configure which information to print
       t = thread
       n = logger name
       l = line number; if 'l' is selected 'c' and 'm' are not used
       c = class name
       m = method name

As you see there is more information printed, e.g. source and line number and log level. As this creates long log lines I made this customizable. How the parameters are passed to the logger is shown later.

First of all I implement a class DebugFormatter which extends java.util.logging.SimpleFromatter as this class is an implementation of the abstract class java.util.logging.Formatter the base of all formatter attached to a log handler. The key part of this class is the method

public String format(LogRecord record) {...}

which gets a log record and returns a string of the information which send to the handler for further action. The format method checks the parameters given and returns a string according to them.

To wire things up I modify the logging.xml file which can be reached from the ‘Application Server Navigator’. Right click on the integrated WLS and select ‘Configure Oracle Diagnostic Logging for …’. This will open a nice graphical overview

Logging.xml

Now I add a new logger by clicking the green ‘+’ sign and specifying the log level and the name of the logger, which is actually the part of the class path the logger reacts on.

Add Logger

this creates a new line in the logging.xml file looking like

Added Line

Next I set up a new log handler in the logging.xml file which uses my DebugLogger class as formatter. Together with the log handler I specify the parameters which configure the output format of the string. The DebugLogger is not used directly, but instead a wrapper class WLSConsoleFormatter used which specifies default parameter set to the DebugFormatter. This way you can omit the parameters in the setup. Below is the resulting log handler entry in the logging.xml file:

        <log_handler name='blog-console-handler'
                     class='de.hahn.blog.consoleformatter.logger.BlogConsoleHandler' level='ALL'
                     encoding='UTF-8'>
            <property name='formatStyle' value='tnlcm'/>
            <property name='formatter'
                      value='de.hahn.blog.consoleformatter.logger.WLSConsoleFormatter'/>
        </log_handler>

To add this you need to change to the source view for the logging.xml file.
Finally I change the added logger to use the new handler

        <logger name='de' level='TRACE:1' useParentHandlers='false'>
            <handler name='blog-console-handler'/>
            <handler name="odl-handler"/>
        </logger>

I have to set the useParentHandlers to false to prevent that the messages get printed multiple times. To be able to analyze the messages with the log analyzer I add the ODL handler too. Now all log messages are printed to the console and to the ODL logger.

Now that the logger are setup in the logging.xml all I need to do is to make the classes available to the WLS instance. For this I build a jar from the project and put the resulting BlogConsoleFormatter.jar in a folder where WLS picks it up while starting. There a a couple of folder, but I choose <ide.system.dir>/DefaultDomain/lib folder. ide.system.dir is also known as the systemfolder of your JDeveloper installation. If you don't know where to find it check this blog. You can either copy the jar into the folder or setup the deployment profile to generate the jar in this folder.

Sample Oiutout

The picture above show a small code sample with the generated output from DebugFormatter. As you see the log lines are marked as links. If you click on such a line you see that you are transfered to the code location of the message.

You can download the source code for the BlogLogConsoleFormatter.zip and a BlogPopupRegion.zip using the ADFLogger to generate messages in different log levels. After downloading the files you need to remove the ‘.doc’ suffix and rename them to ‘.zip’ as the files are normal zip files.
The sample workspaces are developed with JDeveloper 11.1.2.0.0, BlogPopupRegion uses the HR schema as DB connection.

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.