Skip Headers
Oracle® Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework
11g Release 1 (11.1.1)

Part Number B31973-03
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

A ADF Faces Configuration

This appendix describes how to configure JSF and ADF Faces features in various XML configuration files, as well as how to retrieve ADF Faces configuration values using the RequestContext API and how to use JavaScript partitioning.

This chapter includes the following sections:

A.1 Introduction to Configuring ADF Faces

A JSF web application requires a specific set of configuration files, namely, web.xml and faces-config.xml. ADF applications also store configuration information in the adf-config.xml and adf-settings.xml files. Because ADF Faces shares the same code base with MyFaces Trinidad, a JSF application that uses ADF Faces components for the UI also must include a trinidad-config.xml file, and optionally a trinidad-skins.xml file. For more information about the relationship between Trinidad and ADF Faces, see Chapter 1, "Introduction to ADF Faces Rich Client".

A.2 Configuration in web.xml

Part of a JSF application's configuration is determined by the contents of its Java EE application deployment descriptor, web.xml. The web.xml file, which is located in the /WEB-INF directory, defines everything about your application that a server needs to know (except the root context path, which is automatically assigned for you in JDeveloper, or assigned by the system administrator when the application is deployed). Typical runtime settings in the web.xmlfile include initialization parameters, custom tag library location, and security settings.

The following is configured in the web.xmlfile for all applications that use ADF Faces:


JDeveloper automatically adds the necessary ADF Faces configurations to the web.xml file for you the first time you use an ADF Faces component in an application.

For more information about the required elements, see Section A.2.2, "What You May Need to Know About Required Elements in web.xml".

For information about optional configuration elements in web.xml related to ADF Faces, see Section A.2.3, "What You May Need to Know About ADF Faces Context Parameters in web.xml".

For information about configuring web.xml outside of ADF Faces, see Developing Web Applications, Servlets, and JSPs for Oracle.

A.2.1 How to Configure for JSF and ADF Faces in web.xml

In JDeveloper, when you create a project that uses JSF technology, a starter web.xml file with default servlet and mapping elements is created for you in the /WEB-INF directory.

When you use ADF Faces components in a project (that is, a component tag is used on a page rather than just importing the library), in addition to default JSF configuration elements, JDeveloper also automatically adds the following to the web.xml file for you:

  • Configuration elements that are related to MyFaces Trinidad filter and MyFaces Trinidad resource servlet

  • Context parameter javax.faces.STATE_SAVING_METHOD with the value of client

When you elect to use JSP fragments in the application, JDeveloper automatically adds a JSP configuration element for recognizing and interpreting .jsff files in the application.

Example A-1 shows the web.xml file with the default elements that JDeveloper adds for you when you use JSF and ADF Faces and .jsff files.

For information about the web.xml configuration elements needed for working with JSF and ADF Faces, see Section A.2.2, "What You May Need to Know About Required Elements in web.xml".

Example A-1 Generated web.xml File

<?xml version = '1.0' encoding = 'windows-1252'?><web-app xmlns:xsi=""
         xsi:schemaLocation="" version="2.5"
  <description>Empty web.xml file for Web Application</description>
    <servlet-name>Faces Servlet</servlet-name>
    <servlet-name>Faces Servlet</servlet-name>


When you use ADF data controls to build databound web pages, the ADF binding filter and a servlet context parameter for the application binding container are added to the web.xml file.

Configuration options for ADF Faces are set in the web.xml file using <context-param> elements.

To add ADF Faces configuration elements in web.xml:

  1. In the Application Navigator, double-click web.xml to open the file.

    By default, JDeveloper opens the web.xml file in the overview editor, as indicated by the active Overview tab at the bottom of the editor window.

    When you use the overview editor to add or edit entries declaratively, JDeveloper automatically updates the web.xml file for you.

  2. To edit the XML code directly in the web.xml file, click Source at the bottom of the editor window.

    When you edit elements in the XML editor, JDeveloper automatically reflects the changes in the Overview editor.

For a list of context parameters you can add, see Section A.2.3, "What You May Need to Know About ADF Faces Context Parameters in web.xml".

A.2.2 What You May Need to Know About Required Elements in web.xml

The required, application-wide configuration elements for JSF and ADF Faces in the web.xml file are:

  • Context parameter javax.faces.STATE_SAVING_METHOD: Specifies where to store the application's view state. By default this value is server, which stores the application's view state on the server. It is recommended that you set javax.faces.STATE_SAVING_METHOD to client when you use ADF Faces, to store the view state on the browser client. When set to client, ADF Faces then automatically uses token-based, client-side state saving. You can specify the number of tokens to use instead of using the default number of 15. For more information about state-saving context parameters, see Section A.2.3, "What You May Need to Know About ADF Faces Context Parameters in web.xml".

  • MyFaces Trinidad filter and mapping: Installs the MyFaces Trinidad filter org.apache.myfaces.trinidad.webapp.TrinidadFilter, which is a servlet filter that ensures ADF Faces is properly initialized in part by establishing a RequestContext object. TrinidadFilter also processes file uploads. The filter mapping maps the JSF servlet's symbolic name to the MyFaces Trinidad filter. The forward and request dispatchers are needed for any other filter that is forwarding to the MyFaces Trinidad filter.


    If you use multiple filters in your application, ensure that they are listed in the web.xml file in the order in which you want to run them. At runtime, the filters are called in the sequence listed in that file.
  • MyFaces Trinidad resource servlet and mapping: Installs the MyFaces Trinidad resource servlet org.apache.myfaces.trinidad.webapp.ResourceServlet, which serves up web application resources (images, style sheets, JavaScript libraries) by delegating to a resource loader. The servlet mapping maps the MyFaces Trinidad resource servlet's symbolic name to the URL pattern. By default, JDeveloper uses /adf/* for MyFaces Trinidad Core, and /afr/* for ADF Faces.

  • JSF servlet and mapping (added when creating a JSF page or using a template with ADF Faces components): The JSF servlet servlet javax.faces.webapp.FacesServlet manages the request processing lifecycle for web applications that utilize JSF to construct the user interface. The mapping maps the JSF servlet's symbolic name to the URL pattern, which can use either a path prefix or an extension suffix pattern.

    By default JDeveloper uses the path prefix /faces/*, as shown in the following code:

      <servlet-name>Faces Servlet</servlet-name>

    For example, if your web page is index.jspx, this means that when the URL http://localhost:8080/MyDemo/faces/index.jspx is issued, the URL activates the JSF servlet, which strips off the faces prefix and loads the file /MyDemo/index.jspx.

A.2.3 What You May Need to Know About ADF Faces Context Parameters in web.xml

ADF Faces configuration options are defined in the web.xml file using <context-param> elements. For example:


The following context parameters are supported for ADF Faces.

A.2.3.1 State Saving

You can specify the following state-saving context parameters:

  • org.apache.myfaces.trinidad.CLIENT_STATE_METHOD: Specifies the type of client-side state saving to use when client-side state saving is enabled by using javax.faces.STATE_SAVING_METHOD. The values for CLIENT_STATE_METHOD are:

    • token: (Default) Stores the page state in the session, but persists a token to the client. The simple token, which identifies a block of state stored back on the HttpSession object, is stored on the client. This enables ADF Faces to disambiguate the same page appearing multiple times. Failover is supported.

    • all: Stores all state information on the client in a (potentially large) hidden form field. It is useful for developers who do not want to use HttpSession.

    Performance Tip:

    Client-side state saving is recommended. However, because of the potential size of storing all state information, it is recommended that you set client-state saving to token.
  • org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS: Specifies how many tokens should be stored at any one time per user, when token-based client-side state saving is enabled. The default is 15. When the number of tokens is exceeded, the state is lost for the least recently viewed pages, which affects users who actively use the Back button or who have multiple windows opened at the same time. If you are building HTML applications that rely heavily on frames, you would want to increase this value.

A.2.3.2 Debugging

You can specify the following debugging context parameters:

  • org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT: ADF Faces, by default, obfuscates the JavaScript it delivers to the client, stripping comments and whitespace at the same time. This dramatically reduces the size of the ADF Faces JavaScript download, but it also makes it tricky to debug the JavaScript. Set to true to turn off the obfuscation during application development. Set to false for application deployment.

  • org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION: By default this parameter is false. If it is set to true, ADF Faces will automatically check the modification date of your JSPs and CSS files, and discard the saved state when the files change.

    Performance Tip:

    When set to true, this parameter adds overhead that should be avoided when your application is deployed. Set to false when deploying your application to a runtime environment.
  • This parameter enables JavaScript logging when the default render kit is The default is OFF. If you wish to turn on JavaScript logging, use one of the following levels: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, and ALL. Set to INFO if you have enabled automated profiler instrumentation code (see in Section A.2.3.7, "Profiling").

    Performance Tip:

    JavaScript logging will affect performance. You should set this value to OFF in a runtime environment.

A.2.3.3 File Uploading

You can specify the following file upload context parameters:

  • org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY: Specifies the maximum amount of memory that can be used in a single request to store uploaded files. The default is 100K.

  • org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE: Specifies the maximum amount of disk space that can be used in a single request to store uploaded files. The default is 2000K.

  • org.apache.myfaces.trinidad.UPLOAD_TEMP_DIR: Specifies the directory where temporary files are to be stored during file uploading. The default is the user's temporary directory.


The file upload initialization parameters are processed by the default UploadedFileProcessor only. If you replace the default processor with a custom UploadedFileProcessor implementation, the parameters are not processed.

A.2.3.4 Resource Debug Mode

You can specify the following:

  • org.apache.myfaces.trinidad.resource.DEBUG: Specifies whether or not resource debug mode is enabled. The default is false. Set to true if you want to enable resource debug mode. When enabled, ADF Faces sets HTTP response headers to let the browser know that resources (such as JavaScript libraries, images, and CSS) can be cached.


    After turning on resource debug mode, clear your browser cache to force the browser to load the latest versions of the resources.

    Performance Tip:

    In a production environment, this parameter should be removed or set to false.

A.2.3.5 User Customization

For more information about enabling and using session change persistence, see Chapter 31, "Allowing User Customization on JSF Pages".

A.2.3.6 Assertions

You can specify whether or not assertions are used within ADF Faces using the parameter. The default is false. Set to true to turn on assertions.

Performance Tip:

Assertions add overhead. Set this value to false in a runtime environment.

A.2.3.7 Profiling

You can specify the following JavaScript profiling context parameters:

  • Specifies whether or not to use the automated profiler instrumentation code provided with the JavaScript Profiler. The default is false. Set to true to enable the JavaScript profile. When the profiler is enabled, an extra round-trip is needed on each page to fetch the profiler data. By default, JDeveloper uses the /WEB-INF/profiler.xml configuration file. To override the location of the profiler.xml file, use the ROOT_FILE context parameter, as described next. You may also want to set DEBUG_JAVASCRIPT to true, to turn off JavaScript obfuscation. You also must set the LOGGER_LEVEL to at least INFO.

  • Specifies the initial profiler.xml file to load, if automated profiler instrumentation code is turned on. By default, JDeveloper uses the /WEB-INF/profiler.xml file if ROOT_FILE is not specified.

A.2.3.8 Facelets Support

Specify the following if you intend to use Facelets with ADF Faces:

  • org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER: Ins{/Emphasis> parameter