• 向后兼容。 支持JSF 1.2涉及的工作太多，而Spring 3.1中出现了太多的好东西，可以忽略。
• MVC注释为王。 @RequestMapping似乎是大多数人的首选方法。 让我们仅支持此功能，并将所有自定义注释保持在最低限度。
• 减少依赖性。 重用内容很不错，但这是一个集成项目，因此集成越少越好。

考虑到这一点，我决定以Web Flow的org.springframework.faces.mvc.JsfView类为灵感。 该类非常好用，因为它只处理MVC的View ，而Model和Controller完全保留在Spring领域中。 JsfView的唯一问题是缺少回发支持。 我们需要以某种方式检测对视图的初始请求和任何后续的JSF回发之间的差异。

由于Spring MVC具有非常灵活的架构，因此这是完全可能的。 我们可以在DispatcherServlet注册多个HandlerMapping和HandlerAdapter bean。 为了支持JSF，我们需要在此链中的某个较高层来检测和处理回发，而将不是回发的所有内容以常规方式处理。 这是事件的一般顺序：

user               dispatcher    @controller|  /some/request      |              ||-------------------->|   maps to    ||                     |------------->|  creates|                     |              |------------> FacesView|                     |                             (/pages/file.xhtml)|                     |   render                        ||                     |-------------------------------->||                     |                           [Delegate to JSF]|  response           |<--------------------------------||<--------------------||                     ||                     || /some/request       || (postback)          ||-------------------->|      postback handler|                     |--------->||                     |    [Delegate to JSF]|  response           |<---------||<--------------------|          ||                     |          |

回发处理程序有几个有趣的问题要处理。 1）我们怎么知道我们是回发。 2）我们如何知道要还原的视图。 显然，回发将是HTTP POST操作，但是我们不能盲目地假设所有POST都是JSF回发。 我们还需要知道要还原的XHTML文件，但是该文件是基于最后一个请求的@Controller做出的决定。
这两个问题的答案是编写我们自己的JSF ResponseStateManager 。 ResponseStateManager是JSF状态管理基础结构的一部分，并负责读取和写入组件状态。 通常，JSF会将状态数据保存在HTTP会话中，并在页面内写入一个隐藏的表单字段，以便以后可以还原。 使用这种机制，我们可以为MVC编写一个附加字段，该字段的存在使我们知道我们有一个回发，而且该值还将使我们知道要还原的XHTML文件。

有了适当的回发处理程序，我们现在可以充分利用Spring和JSF的优势。 我们可以使用@RequestMapping批注来构建富有表现力的URL，并使用JSF组件来呈现复杂的网页。 如果愿意，我们甚至可以基于完全不同的技术为同一URL返回不同的视图（例如，通过检查HTTP标头，我们可能决定返回JSF页面或XML文档）。

如果您想查看回发处理程序代码，请参见此处 。 通常将其作为移动代码库的警告。

参考： 集成Spring和JavaServer Faces：来自JCG合作伙伴 Phillip Webb的 MVC 细节   在Phil Webb的Blog上 。