Enable Oracle JCS to access External REST API

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

null

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

null

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

null

Next a ‘Security Rule’ can be created like

null

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

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.

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.

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

Error dialog


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

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

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

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

Add Logger


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

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

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.