JSF request processing process (i) Facesservlet initialization

In JSF applications, a servlet, called Javax.faces.webapp.FacesServlet, is configured inside the Web.xml, so you can know that viewing and understanding a request's processing can begin here. From the official website download JSF source code, the project name is more strange, called "Mojarra", I see the version is 1.2_12_B01. It contains two subprojects, one is Jsf-api, most of which are interfaces and a few key classes. Another project called Jsf-ri, the "Ri" evil after a long time, finally in the brothers to remind to understand is reference implementation meaning. Jsf-api is part of the Java EE Standard, where the type package names begin with Javax.faces, and the Jsf-ri project is a reference implementation of Sun's JSF standards, where the package names of the types begin with Com.sun.faces.

1.FacesServlet Initialization (Facesservlet#init)

When the system starts, the Facesservlet is initialized and the Init method is invoked. There are two main things to do, one is to initialize the Facescontextfactory, the other is to initialize the Lifecycle object. In the JSF-API project, the Facesservlet class is the implementation class for a servlet interface, and facescontextfactory and lifecycle are interfaces. The implementation classes for these two interfaces are available in the Jsf-ri project, respectively, the Com.sun.faces.context.FacesContextFactoryImpl and Com.sun.faces.lifecycle.LifecycleImpl classes. A fact to take for granted: Facesservlet initialization is based on a few configurations to determine what the specific facescontextfactory and lifecycle implementation classes are, which is where the JSF standard and JSF implementations converge. The other JSF implementations that want to myfaces and so on should be two ways to change the value of the configuration that is needed in the Facesservlet init method, and then enable your own facescontextfactory implementation and lifecycle implementation. The following process is all about the logic of your own. The second method is stupid, the likelihood is small, is to replace the Facesservlet cover, which does not need to read what configuration, directly using their own implementation class can-but this approach is not expected to conform to the JSF specification, I think only I wait for the shrimp people can do it. The main code is as follows:

1　facesContextFactory　=　(FacesContextFactory)FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
2
3　LifecycleFactory　lifecycleFactory　=　(LifecycleFactory)FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);

Looking back at the results of the initialization, Facescontextfactory was apparently used to produce facescontext. And Facescontext can be seen as a requestwrapper (note that this facecontext and ServletContext are not the same, ServletContext is a Web application with only one global object, corresponding to a web Application, and a facescontext corresponds to a request, in addition, Requestwrapper this statement is not strict, in fact, facescontext inside also packed ServletContext, Response, etc.). Lifecycle can be viewed as a filter chain (similar to the filter Chain inside the servlet specification). As a result, the entire JSF request processing process is actually a facecontext user request, through a lifecycle process similar to a filter chain.