Much has been made of the fact that JavaServer Faces promotes a page oriented architecture for applications, typically associating a request scoped "backing bean" with each page to contain event handlers and/or submitted values. Indeed, Shale itself offers extended support for this paradigm by virtue of its View Controller feature. This is in contrast to the action oriented architecture typically found in web application frameworks like Struts 1.x.
A second aspect of action oriented frameworks, however, is also useful. They typically implement an application level controller (in the sense of the Model/View/Controller design pattern) through which all HTTP requests to the application are funneled. Various frameworks offer mechanisms to customize the lifecycle processing that is performed, for example:
RequestProcessorand override the processXxx() series of methods that perform the actual processing of the request.
PhaseListenerinstances that receive control before or after the standard phases of the request processing lifecycle, which can exert control over what happens next.
PhaseListenerapproach to customizing the request processing lifecycle. However, it also supports Application Manager functionality that can customize processing before or after the standard JavaServer Faces lifecycle, as described below.
The Application Manager feature of Shale provides application wide services as described below:
As described in Configuring
Your Application For Shale, you are requested to configure a
map it to process incoming URLs (typically using the URL pattern
/* to process all requests to this application).
This filter receives control both before and
after the standard JavaServer Faces request
processing lifecycle (which is implemented as a servlet).
ShaleApplicationFilter imposes a standard request
processing lifecycle using
technology, which provides both preprocessing and postprocessing
hooks where the application developer can plug in additional
behavior at these two points in time. The following processing
is performed for each request:
ShaleWebContext(which implements the Commons Chain
Contextinterface) to represent the current request. This instance will be passed in to any Commons Chain commands involved in processing the current request.
ShaleWebContextinstance as a request scope attribute under the key identified by manifest constant
ShaleApplicationFilter.CONTEXT_ATTRso that it is available to later processing stages.
shalecatalog. If such a command (or chain) exists:
true(indicating that processing for the entire request should be considered complete), remove the request scope attribute that was added and earlier, and exit.
FilterChainargument passed in, which will ultimately trigger the standard JavaServer Faces processing when the incoming URL is mapped to
shalecatalog. If such a command (or chain) exists, execute it.
preprocesscommands that perform request filtering based on matching incoming request values to regular expressions. See the Javadocs for this class for more information.
Three concrete implementations based on this abstract base class are also provided:
ContextRelativePathFilterdescribed above, using it to disallow direct access to JSP pages by URLs manually typed in to the browser. This is accomplished by the following configuration stored in the
<catalogs> <catalog name="shale"> ... <command className="org.apache.shale.application.ContextRelativePathFilter" includes="\S*\.xml,\S*\.faces,\S*\.html,\S*\.gif,\S*\.jpg,index\.jsp" excludes="\S*\.jsp,\S*\.jspf"/> ... </catalog> </catalogs>
ContextRelativePathFilter instance is configured to pass
through context relative paths that match one of the regular expressions in
includes attribute, while disallowing access for context
relative paths that match one of the regular expressions in the
excludes list. With these settings, direct access to any URL
.jspf (other than to a resource
index.jsp) will be prevented.