JSF请求处理过程详解

开发 后端
JSF请求处理过程从web.xml里面配置的一个Servlet开始,本文将向你详细介绍整个JSF请求处理的详细过程。

JSF应用中,在web.xml里面配置了一个Servlet,叫做javax.faces.webapp.FacesServlet,于是可以知道,查看、了解一个请求的处理过程可以从这里开始。从官方网站上下载JSF的源代码,项目名比较古怪,叫做“mojarra”,我看的版本是1.2_12_b01。里面包含了两个子项目,一个是jsf-api,里面大多是接口以及少量关键类。另外一个项目叫做jsf-ri,对着这个"ri"邪念了半天之后,终于在兄弟提醒之下想明白了是reference implementation的意思。jsf-api是JavaEE标准的一部分,里面的类型包名都是以javax.faces开头的,而jsf-ri项目是sun针对JSF标准的一个参考实现,里面的类型的包名都是以com.sun.faces开头的。

FacesServlet初始化(FacesServlet#init

JSF请求处理过程中,系统启动的时候,会初始化FacesServlet,调用其中的init方法。里面主要做了两件事情,一个是初始化FacesContextFactory,另外一个是初始化Lifecycle对象。在jsf-api项目中,FacesServlet类是一个Servlet接口的实现类,而FacesContextFactory和Lifecycle都是接口。在jsf-ri项目中有这两个接口的实现类,分别是com.sun.faces.context.FacesContextFactoryImpl和com.sun.faces.lifecycle.LifecycleImpl类。一个想当然的事实:FacesServlet初始化的时候要根据一些配置来判断具体的FacesContextFactory和Lifecycle实现类是什么,也就是在这里,“JSF标准”和“JSF实现”接轨了。想来MyFaces等等的其他JSF实现应该不外乎两种方式,一种是改变FacesServlet的init方法中需要用到的配置的值,于是启用自己的FacesContextFactory实现和Lifecycle实现,后面的处理过程就全部走自己的逻辑了。第二种方法笨一点,可能性不大,就是把FacesServlet覆盖替换掉,其中也不需要读什么配置了,直接使用自己的实现类即可——不过这种做法估计不符合JSF规范,想来只有我等虾米民众能做的出来。主要代码如下:

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

回头再来看初始化的结果,FacesContextFactory很明显是用来生产FacesContext这么个东西的。而FacesContext可以看做是一个RequestWrapper(注意这个FaceContext和ServletContext不一样,ServletContext是一个Web应用只有一个的全局对象,对应的是一个Web application,而一个FacesContext对应的是一个request,另外,RequestWrapper这个说法不严格,实际上FacesContext里面也包装了ServletContext、Response等)。而LifeCycle可以看做是一个过滤器链(类似于servlet规范里面的Filter Chain)。于是,整个JSF请求处理过程,实际上就是包装成为FaceContext的用户请求,通过类似于一个Filter Chain的LifeCycle的过程。

这总览,很明显是看FacesServlet的service方法。在FacesServlet的初始化过程中,构造出了全局的FacesContextFactory对象和LifeCycle对象。可以把FacesContextFactory看做是一个“请求包装工厂”,于是很明显,每当一个请求到达FacesServlet的时候,第一步便是拿着请求,到包装工厂里面包装一下,而包装的结果就是一个FacesContext。代码如下:

FacesContext context = facesContextFactory.getFacesContext(servletConfig.getServletContext(), request, response, lifecycle);

在包装过程中,实际上是创建了一个com.sun.faces.context.FacesContextImpl对象,FacesContextImpl类继承了jsf-api项目中的javax.faces.context.FacesContext。FacesContextImpl的构造方法的第一个参数是一个叫做ExternalContext的接口的实现,查看其源代码,可以看到ExternalContextImpl类耦合了Servlet API,而FacesContextImpl与Servlet API无关。实际上,在这里,做到了JSF可以不仅仅使用在Servlet环境中,正如ExternalContext接口的注释中所说,在Servlet环境中使用JSF和在Portlet环境中使用JSF的不同,实际上就是使用了不同的ExternalContext。在FacesContextFactoryImpl中构造FacesContextImpl的代码如下:

  1. FacesContext ctx = new FacesContextImpl  
  2.      (new ExternalContextImpl((ServletContext) sc,  
  3.      (ServletRequest) request,(ServletResponse) response),  
  4.       lifecycle); 

FacesContextImpl的构造方法中,还做了另外一件事情,就是根据配置确定了RenderKitFactory,显然不同的RenderKitFactory可以产生不同的RenderKit,而不同RenderKit对象是针对不同客户端的,所以对于浏览器、移动设备等等,会有不同的RenderKit。FacesContextImpl的构造方法中代码如下:

  1. this.externalContext = ec;  
  2. setCurrentInstance(this);  
  3. this.rkFactory = (RenderKitFactory)FactoryFinder.getFactory(FactoryFinder.RENDER_KIT_FACTORY); 

在代码中我们经常使用FacesContext.getCurrentInstance()这个静态方法来获取与当前请求对应的FacesContext对象,实际上是在FacesContext类里面有一个静态的ThreadLocal对象用来存放了当前请求线程对应的FacesContext对象,于是上面的代码中setCurrentInstance(this)就是把当前构造出来的这个FacesContext对象放到了ThreadLocal里面。

FacesContext创建出来以后,正如上面所说,要让他经过LifeCycle这个“Filter Chain”的逐步处理了。那么,Filter Chain里面放的是一个一个Filter,那么LifeCycle这个Chain里面放的是什么呢?答案是Phases。

FacesServlet让FaceContext通过LifeCycle的处理,分成了两个部分。一个部分是调用LifeCycle的execute方法,执行逻辑,第二个部分是调用LifeCycle的render方法,呈现响应。FacesServlet.service中代码如下:

  1. lifecycle.execute(context);  
  2. lifecycle.render(context); 

在LifeCycleImpl这个实现中,存放了一个Phase对象的数组,存放了7个Phase。其中第一个是null,然后依次是视图重建、应用请求值、验证、更新模型值、执行应用程序、呈现响应。在execute方法中,调用了从视图重建开始到执行应用程序为止的5个Phase,而在render方法中,调用了最后一个Phase,也就是呈现响应。在LifeCycleImpl类中,代码如下:

  1. //The Phase instance for the render() method  
  2.     private Phase response = new RenderResponsePhase();  
  3.  
  4.     // The set of Phase instances that are executed by the execute() method  
  5.     // in order by the ordinal property of each phase  
  6.     private Phase[] phases = {  
  7.         null// ANY_PHASE placeholder, not a real Phase  
  8.         new RestoreViewPhase(),  
  9.         new ApplyRequestValuesPhase(),  
  10.         new ProcessValidationsPhase(),  
  11.         new UpdateModelValuesPhase(),  
  12.         new InvokeApplicationPhase(),  
  13.         response  
  14.     }; 

在Servlet Filter中,可以由每一个Filter来决定是否要调用下一个Filter,从而决定是否让请求继续通过Filter Chains中的后续Filter,是链式调用的过程。而在LifeCycle的execute方法中,是用一个for循环顺序执行几个Phase。在每一个Phase执行完之后,都会检查FaceContext对象中是否设置了停止后续处理直接呈现响应的标志(renderResponse)或者已经完成了响应无需后续处理也不需要经过呈现响应阶段了(responseComplete),如果标志为true,那么就不再执行后续Phase。

LifeCycleImpl的execute方法主要代码如下:

  1. for (int i = 1, len = phases.length -1 ; i < len; i++) { // Skip ANY_PHASE placeholder  
  2.  
  3.              if (context.getRenderResponse() ||  
  4.                  context.getResponseComplete()) {  
  5.                  break;  
  6.              }  
  7.    
  8.             phases[i].doPhase(context, this, listeners.listIterator());  
  9.    
  10.   } 

在LifeCycle的render方法中,也会检查FacesContext的responseComplete状态,如果为true,那么就不再执行render Phase。于是我们此刻知道了在我们自己所写的一些代码或者JSF库里面的一些代码中,调用FacesContext的responseComplete方法和renderResponse得作用原理。render方法主要代码如下:

  1. if (!context.getResponseComplete()) {  
  2.        response.doPhase(context, this,listeners.listIterator());  
  3.  } 

另外注意,Phase这个概念、接口,以及几个实现,都是jsf-ri项目中的,而在jsf-api中不存在Phase这个概念。所以,LifeCycle是JSF标准的内容,而通过几个Phase来处理请求这种实现是sun的参考实现的做法。

最后,我们在JSF请求处理过程中可以看到对于每一个phase都调用了doPhase方法,同时把LifeCycle和FacesContext当做参数传入了。值得注意的是,所谓的phaseListener,也传入了phase的doPhase方法中,由此大约能够想明白这个“阶段监听器”的道理了。

 

【编辑推荐】

  1. 使用Acegi保护JSF应用程序
  2. JSF的技术与组件
  3. JSF开发问题和解决
  4. 浅析对JSF项目的单元测试
  5. Facelets专为JSF设计的视图技术
责任编辑:佚名 来源: blogjava
相关推荐

2010-06-02 18:00:05

Postfix邮件

2010-06-09 18:17:20

Postfix邮件

2009-09-24 17:11:53

Hibernate处理

2009-07-24 10:57:41

ASP.NET ISAIIS6

2011-04-13 14:57:11

ASP.NET请求处理

2011-04-13 15:50:49

.htmHTTP请求处理

2011-09-02 14:09:47

OracleDML命令

2009-07-15 16:29:41

Swing绘画

2011-02-21 13:26:47

Postfix邮件处理

2011-04-11 16:42:05

Oracle无法启动

2013-06-20 10:17:34

Android应用

2009-01-27 17:32:00

虚拟化部署案例

2021-02-01 09:00:34

Ceph octopu集群运维

2020-11-12 07:32:53

JavaScript

2018-05-30 09:47:02

2011-07-04 14:38:43

QT Qevent

2021-11-08 08:29:57

Oracle数据库后端开发

2019-08-19 11:07:41

SQL数据库优化

2009-07-28 11:32:41

光纤链路故障

2022-06-01 06:17:42

微服务Kafka
点赞
收藏

51CTO技术栈公众号