不知道为什么.MANAGE BEAN的SETXXX和GETXXX都在应用请求值阶段执行GETXXX....绑定的都SETXXX.GETXXX.
为什么呢?
------解决方案--------------------
zt: http://www.51jsf.cn/viewthread.php?tid=12&extra=page%3D1
JSF 生命周期 的五个阶段
JSF 程序生命周期的 5 个阶段如下（注意每个阶段的事件处理）：
1) 恢复视图
2) 应用请求的值；处理验证
3) 更新模型值；处理事件
4) 调用程序；处理事件
5) 进行响应；处理事件
这 5 个阶段显示了 JSF 通常处理 GUI 的顺序。虽然这个清单列出了每个阶段中事件处理的可能执行顺序，但是 JSF 的生命周期很难是固定一成不变的。您可以通过忽略某个阶段或合并整个生命周期从而对执行顺序进行修改。例如，如果一个无效的请求值被拷贝到一个组件中，那么当前的视图就会重新显示，而有些阶段就可能不会执行。在这种情况中，您可以执行一个 FacesContext.responseComplete 方法调用，将用户重定向到一个不同的页面上，然后使用请求分发器（从 FacesContext 中的请求对象中获得）将其转发到一个适当的 Web 资源上。另外，您可以调用 FacesContext.renderResponse 重新显示原来的视图。
关键是让生命周期构成您的开发项目，而不完全依赖于生命周期。在需要时，您可以修改生命周期，而不用担心破坏您的程序。在大部分情况中，您会发现 JSF 的生命周期是值得遵守的，因为它的逻辑非常好。表单必须在任何应用程序逻辑执行之前进行验证，并且在进行验证之前，必须对域中的数据进行转换。遵守生命周期的规定，可以让您更自由地考虑有关验证和转换的问题，而不是请求处理本身的阶段。有一点非常重要：其他 Web 框架也都具有类似的生命周期；它们只不过是没有很好地进行宣传。
有些使用 JSF 的开发者可能从来都不会编写一个组件，也不会对框架进行任何扩展；而另外一些人则专注于这种任务的开发。尽管 JSF 的生命周期与大部分那其他项目都是相同的，但是根据在项目中的角色您可以采用不同的阶段。
如果您更专注于通用的应用程序开发，就可能会关注请求处理生命周期的中间阶段：
应用请求值
更新模型值
调用程序
如果您专注于 JSF 组件的开发，就可能会关注于整个生命周期中的第一个阶段和最后一个阶段：
恢复视图
进行响应
在开始之前，首先来看一下附件中的图，这是一个有关 JSF 生命周期的图。
阶段 1：恢复视图
在 JSF 生命周期的第一个阶段中，会有一个来自 FacesServlet 控制器的请求。控制器会对请求进行考查，并提取出视图的 ID，这是由 JSP 页面的名字来确定的。
JSF 框架控制器使用这个视图 ID 来为当前的视图查找组件。如果这个视图尚未存在，那么 JSF 控制器就会创建它。如果这个视图早已存在，那么 JSF 控制器就会使用它。这个视图包含了所有的 GUI 组件。
生命周期的这个阶段表示为三个视图实例：新视图、原始视图和后视图，每个视图的处理方式都不相同。在 新视图 的情况中，JSF 会构建 Faces 页面的视图，并将事件处理程序和验证程序绑定到组件上。这个视图被保存在一个 FacesContext 对象中。
FacesContext 对象包含了 JSF 用来管理当前会话中当前请求的 GUI 组件状态所需要的所有状态信息。FacesContext 将视图保存在自己的 viewRoot 属性中；viewRoot 包含了当前视图 ID 的所有 JSF 组件。
在 原始视图 的情况中（第一次加载的是一个页面），JSF 会创建一个空视图。这个空视图会在用户事件产生时进行填充。JSF 可以直接从原始视图过渡到进行响应的阶段。
在 后视图（postback） 的情况中（用户返回之前访问过的页面），包含页面的视图早已经存在了，因此只需要进行恢复就可以了。在这种情况中，JSF 就使用现有视图的状态信息来重构状态。后视图的下一个阶段是应用请求值。
阶段 2：应用请求值
应用请求值 阶段的目的是让每个组件检索自己当前的状态信息。这些组件必须首先通过 FacesContext 对象进行检索或创建（使用其值）。虽然组件值也可以从 cookie 或头文件中进行检索，但是它们通常是通过请求参数进行检索的。
如果一个组件的即时事件处理属性 没有 设置为 true，那么就会对这些值进行转换。因此，如果 域 被绑定到一个 Integer 属性上，那么该值就会被转换为一个 Integer 类型。如果值的转换失败了，那么就会生成一个错误消息，并在 FacesContext 中进行排队，在产生响应的阶段会显示其中的消息，同时还会显示所有的验证错误。
如果一个组件的即时事件处理属性 的确 被设置为 true，那么这些值就会被转换为适当的类型，并进行有效性验证。然后转换后的值会被保存到组件中。如果值转换或值的有效性验证失败了，就会生成一个错误消息，并在 FacesContext 中进行排队，在产生响应的阶段会显示其中的消息，同时还会显示所有的验证错误。
即时事件处理
JSF 的即时事件处理属性用来处理那些通常不必要对整个表单进行有效性验证的事件。例如，假设一个雇员表单中有一个单选按钮来说明他是否是经理。当他选中 Manager 选项时，应用程序就会为经理生成一些内容。由于单选按钮只用来生成一个列表，而不需要用户填写整个表单，因此不需要对整个表单进行有效性验证。在这种情况中，您就可以使用即时事件处理。
处理验证
生命周期中的第一个事件处理发生在应用请求值阶段之后。在这个阶段中，每个组件都有一些值需要根据应用程序的验证规则进行有效性验证。这些验证规则可以是预先进行定义的（JSF 中提供的），也可以由开发者进行定义。用户所输入的值会与这些验证规则进行比较。如果说输入的值无效，就会向 FacesContext 中添加一个错误消息，并且该组件会被表示为无效的。如果一个组件被表示为无效的，那么 JSF 就会转到产生响应的阶段，在这个阶段中会显示当前的视图，以及验证错误消息。如果没有有效性验证错误，那么 JSF 就会转到更新模型值的阶段。
阶段 3：更新模型值
JSF 应用程序生命周期中的第三个阶段 ——更新模型值 —— 负责更新服务器端模型的实际值，通常来讲，这都是通过更新后台 bean（称为管理 bean）的属性实现的。只有那些与组件值绑定在一起的 bean 属性才会被更新。注意这个阶段发生在有效性验证之后，因此可以确保拷贝到 bean 属性的值都是有效的（至少在表单域一级都是有效的；在业务规则一级仍可能无效）。
阶段 4：调用程序
在生命周期的第四个阶段 ——调用程序 —— 中，JSF 控制程序会调用程序来处理 表单 的提交操作。组件值已经经过了类型转换和有效性验证，并被应用到模型对象中了，因此您现在可以使用它们来执行应用程序的业务逻辑了。
在这个阶段，您还可以为一个给定的序列或很多可能的序列指定后面的逻辑视图，这可以通过为一次成功的表单提交定义一个特定的结果并返回这个结果来实现。例如：在成功输出时，将用户重定向到下一页中。要让这种导航工作能够起作用，您需要在 faces-config.xml 文件中创建一个到 成功输出 的映射作为一条导航规则。一旦导航发生之后，您就转换到生命周期的最后一个阶段了。
阶段 5：进行响应
在生命周期的第五个阶段 ——进行响应 —— 中，您可以在视图中显示当前状态中的所有组件。