Faces-config.xml

faces-config.xml is a key configuration file type within a JavaServer Faces (JSF) software implementation.

The Java Platform, Enterprise Edition specification refers to this type of file as an Application Configuration Resource File.

There may be more than one such file within a Java Enterprise application.

* Most simple Java based dynamic web applications make their configuration files available as a resource named /WEB-INF/faces-config.xml

* If a resource named /META-INF/faces-config.xml exists in any of the JAR files within the web application's /WEB-INF/lib/ directory or in parent class loaders, it is loaded as a configuration resource.
* Enterprise-scale applications that delegate partial responsibility for maintaining configuration files to separate groups may specify one or more paths to multiple faces-config.xml configuration files. The relevant context initialization parameter is called javax.faces.application.CONFIG_FILES. Multiple (comma-delimited) paths to Application Configuration Resource Files may be specified.

The faces-config.xml file effectively provides the glue that links together multiple elements in JSF's interpretation of the Model-view-controller (MVC), Factory Pattern and Inversion of Control (IoC) software design patterns.

By centralising all of these configuration aspects of JSF in a single location, faces-config.xml itself implements the Encapsulation design pattern.

The format of the file is XML version 1.0 compliant. The structure of the file is defined by a Document Type Definition (DTD), which is subject to license terms of Sun Microsystems Inc. This is published at:

http://java.sun.com/dtd/web-facesconfig_1_0.dtd

The top level definition elements within a Version 1.0 Java Server Faces configuration are as follows:

* application - JSF's solution for defining classes that have application-wide scope i.e. only a single instance of the object will exist

* component - JSF's solution for defining concrete user interface implementation classes that have a unique relationship with a specified type identifier. Component definitions also include related properties (JavaBean configuration elements) and attributes (configuration elements implemented by component).

* converter - JSF's solution for defining concrete converter implementation classes that have a unique relationship with a specified converter identifier. Converter definitions also include related properties (JavaBeans properties of the Converter implementation class that may be configured to affect the operation of the Converter) and attributes (configuration elements that may be configured on the corresponding User Interface Component in order to affect the operation of the Converter).

* factory - JSF's solution for enabling definition of factory objects, that instantiate other objects, enabling implementation of the Factory Pattern

* lifecycle - JSF's solution for enabling the specification of modifications to the default "lifecycle" of a web application.

* managed-bean - JSF's solution for instantiating & initialising Java objects, enabling implementation of the Inversion of Control design pattern

* navigation-rule - JSF's solution for controlling transitions between JSP views

* referenced-bean - JSF's solution for capturing at design time the promise that a Java object of the specified type will exist at runtime in some scope, under the specified key.

* render-kit - JSF's solution for defining concrete RenderKit implementation classes that have a unique relationship with a specified render-kit-id. If no render-kit-id is specified, the identifier of the default RenderKit (RenderKitFactory.DEFAULT_RENDER_KIT) is assumed.

* validator - JSF's solution for defining concrete Validator implementation classes that have a unique relationship with a specified validator identifier. Validator definitions also include related properties (JavaBeans properties of the Validator implementation class that may be configured to affect the operation of the Validator) and attributes (configuration elements that may be configured on the corresponding User Interface Component in order to affect the operation of the Validator).

Design critique of faces-config.xml

Although the structure and usage of the faces-config.xml achieves some generally desirable goals (central configuration control, flexibility to delegate local configuration), JSF configurations are often regarded as being somewhat brittle, non-portable, non-performant and difficult to manage.

Making a wrong configuration change to a faces-config.xml file can break an application after it has been tested.

In part this stems from the use of raw text XML to perform functions typically performed by source code (which would achieve a higher level of control) or by system configuration parameters stored in an application's database (which would achieve a higher level of flexibility to make on the fly changes).

Alternative frameworks such as Wicket (see ptrthomas link below) or ItsNat use only HTML and Java source code.

The forthcoming JSF 2.0 standard is set to include new features that allow software configuration aspects that are currently managed through the use of faces-config.xml file(s) to be packaged into robust software deliverables that have no dependencies on external text configuration data in order to be deployed into compliant application server containers.

External References

* http://java.sun.com/javaee/5/docs/tutorial/backup/doc/JSFConfigure2.html - Authoritative Sun Microsystems tutorial on JSF configuration
* http://bugs.sakaiproject.org/confluence/download/attachments/15032/IntroToJSF.ppt?version=1 - Good introduction to JSF and faces-config.xml (Powerpoint slides)
* http://horstmann.com/corejsf/faces-config.html
* http://www.oracle.com/technology/tech/java/newsletter/articles/jsf_pojo/index.html
* http://ptrthomas.wordpress.com/ - compares JSF unfavourably with Wicket and Spring