Monday Jun 18, 2012

Pretty URL in ADF Faces of JDeveloper

Many features planned for Oracle JDeveloper 12c find their way into current releases of Oracle JDeveloper 11g R1 and JDeveloper 11g R2. One example of such a feature is "pretty URL" - or "clean URL" as the Oracle JDeveloper 11g R2 ( documentation puts it.

"A.2.3.24 Clean URLs

Historically, ADF Faces has used URL parameters to hold information, such as window IDs and state. However, URL parameters can prevent search engines from recognizing when URLs are actually the same, and therefore interfere with analytics. URL parameters can also interfere with bookmarking.

By default, ADF Faces removes URL parameters using the HTML5 History Management API. If that API is unavailable, then session cookies are used.

You can also manually configure how URL parameters are removed using the context parameter Set the parameter to off so that no parameters are removed. Set the parameter to useHistoryApi to only use the HTML5 History Management API. If a browser does not support this API, then no parameters will be removed. Set the parameter to useCookies to use session cookies to remove parameters. If the browser does not support cookies, then no parameters will be removed."


So basically, what this part in the documentation says is:

  • In JDeveloper 11g R2 (, Oracle ADF Faces automatically removes its internally used dynamic parameters from the URL
  • You can influence the setting with the prettyURL.OPTIONS context option, which however is not recommended you to do because the default behavior is able to detect if the browser client supports HTML 5 History management or not. In the latter case it the uses a session cookie and if this doesn't work, falls back to the "old" URL parameter adding.
The information that is not so explicit and clearly mentioned in the documentation is that this is only for ADF Faces parameters (such as _afrLoop, Adf-Window-Id, etc.), but not the ADF controller token (_adf.ctrl-state)! Removing the ADF controller token is an enhancement request that will be implemented in Oracle JDeveloper 12c

Monday Mar 19, 2012

URL Task Flow vs. WSRP Portlets

A URL task flow is bounded task flow that is deployed as a stand-alone Java EE application on a remote server with its URL Invoke property set to url-invoke-allowed. The URL task flow is accessed either from a direct browser GET request or, when called from another ADF application, through the task flow call activity.

For more information about how to invoke URL task flows from a task flow call activity see chapter 15.6.4 How to Call a Bounded Task Flow Using a URL of the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework at

Compared to WRSP portlets, URL task flows in Oracle JDeveloper 11g R1 and R2 have a functional limitation in that they cannot be embedded as a region on a page but require the calling ADF application to navigate off to another application and page. The difference between a URL task flow call using the task flow call activity and a simple redirect to a remote Java EE application is that the URL task flow has a state token attached that allows to restore the state of the calling application upon task flow return.

A use case for a URL task flow call activity is a "yellow page lookup" scenario in which different ADF applications use an URL task flow to lookup people, products or similar to return a selected value to the calling application.

Note that URL task flow calls need to be performed from a bounded or unbounded top level task flow of the calling application. If called from a region (using the parent call activity) in a page, the region state is not recovered upon task flow return.

ADF developers recently have identified URL task flows as an architecture pattern to partition their ADF applications into independently deployed Java EE applications. While this sounds like a desirable use of the URL task flow feature, it is not possible to achieve for as long as URL task flows don't render as an ADF region.

Tuesday May 10, 2011

How-to efficiently redirect an ADF Faces view using ADFc

ADF Faces developers use facesContex.getExternalContext().redirect(String) to issue a GET request to a JSF view. Using ADFc, the redirect URL should neither be read from the current UIView root directly or provided in the form /faces/<viewId name>. Instead, have the controller generating the redirect String for a specific viewId as shown below:

FacesContext fctx = FacesContext.getCurrentInstance();
ExternalContext ectx = fctx.getExternalContext();

String viewId = "... add viewId...."
ControllerContext controllerCtx = null;
controllerCtx = ControllerContext.getInstance();
String activityURL = controllerCtx.getGlobalViewActivityURL(viewId);

} catch (IOException e) {
//Can't redirect


Why? Because a redirect is a Get request and you don't want ADFc to treat it as a new application request but instead retrieve the internal controller state. For this you need the state toke in the redirect URL, which is what the code line above does


A blog on Oracle JDeveloper, ADF, MAF, MCS and other mobile and web topics inspired by questions and answers posted on the OTN forums.

Frank Nimphius


« March 2015