Information about the view components in the web application and
information about how control flows through the application is contained in a special
configuration file named faces-config.xml, shown in Listing below. Although faces-config.xml
can contain a lot of information about a web application, for this example we need it to do only
two things: identify the flow of control from searchForm.jsp to searchResults.jsp, and
identify the JavaBean used by the application.
The faces-config.xml file identifies the JavaBeans used by the
web application in the <managed-bean> element. You will have a
<managed-bean> element for every JavaBean used by your web application. The <managed-bean> element in
Listing above contains three subelements:
- The first subelement is the name used to identify the
JavaBean in a JSP page. In Listing above
the name is given as flight; this is why both searchForm.jsp and
searchResults.jsp can access an instance of the JavaBean by using the expression
- The second element is the fully qualified class name of the
JavaBean class. This name tells the JSP container which class to load and instantiate to
create an instance of the JavaBean.
- The third element identifies the scope of the object.
Session scope means that the object exists for the entire interaction between the user and
the application. The container must persist the object across multiple request/response cycles,
until the user’s session is terminated.
The faces-config.xml file is also used to tell the controller
how to navigate through the application. Navigation flow is specified in
<navigation-rule> elements. Our example needs only one element. In general, a <navigation-rule> element
identifies the start page, a condition, and the page to navigate to when the condition occurs.
In our example, the start page is searchForm.jsp. If the page
request is submitted with an outcome of submit, control is transferred to
searchResults.jsp. Looking at Listing, you can see that the <commandButton> element has an action of
submit; when the button is clicked and the form is submitted, this action matches the
<from-outcome> of the <navigation-rule>. The <navigation-rule> element also includes an empty
<redirect> element. With this element, the response is created by causing the browser to
redirect to the searchResults.jsp page, which also updates the address bar in the browser. Without
this element, the response is still created correctly and sent to the browser, but the
address bar of the browser will not be updated and will still display the address for the originating
We need just one final piece for our web application. In this example, our default page will be a standard HTML page
that redirects to the correct URL for a JSF application. Listing below shows
<meta http-equiv="Refresh" content= "0; URL=searchForm.faces"/>
You can see that that the redirect URL is searchForm.faces.
However, there is no component in our application named searchForm.faces. How then does the web
application know which page to serve? All requests that are JSF requests are
directed to the controller for the application, which is a servlet supplied as part of the JSF
reference implementation.While deploying this example, you will specify that all
URLs of the form *.faces should be sent to the controller servlet. This servlet then converts
the searchForm.faces request to searchForm.jsp, processes the JSP page, and sends the response
to the browser.