这就是解决方法，对我来说很管用。

<p:commandButton id="b1" value="Save" process="userGroupSetupForm"
                    actionListener="#{userGroupSetupController.saveData()}" 
                    update="growl userGroupList userGroupSetupForm" />

这里，process="userGroupSetupForm"属性是Ajax调用的强制属性。actionListener从@ViewScope Bean调用一个方法。也更新咆哮消息，数据表:userGroupList和表单:userGroupSetupForm。

如果你的h:commandLink在h:dataTable中，还有另一个原因，为什么h:commandLink可能不起作用:

绑定到h:dataTable的底层数据源也必须在单击链接时触发的第二个JSF-Lifecycle中可用。

因此，如果底层数据源是请求作用域，h:commandLink将不起作用!

我有很多有趣的调试问题，其中一个<h:commandLink>的动作在richfaces数据表拒绝发射。这张桌子曾经在某个时候工作过，但没有明显的原因就停了下来。我想尽了一切办法，却发现我的rich:datatable使用了错误的rowKeyConverter，它返回了richfaces愉快地用作行键的空值。这阻止了我的<h:commandLink>动作被调用。

这就是解决方法，对我来说很管用。

<p:commandButton id="b1" value="Save" process="userGroupSetupForm"
                    actionListener="#{userGroupSetupController.saveData()}" 
                    update="growl userGroupList userGroupSetupForm" />

这里，process="userGroupSetupForm"属性是Ajax调用的强制属性。actionListener从@ViewScope Bean调用一个方法。也更新咆哮消息，数据表:userGroupList和表单:userGroupSetupForm。

<ui:composition>  
  <h:form id="form1">
    <p:dialog id="dialog1">
      <p:commandButton value="Save" action="#{bean.method1}" /> <!--Working-->
    </p:dialog>
  </h:form>

  <h:form id="form2">
    <p:dialog id="dialog2">
      <p:commandButton value="Save" action="#{bean.method2}" /> <!--Not Working-->
    </p:dialog>
  </h:form>
</ui:composition>

来解决;

<ui:composition>  
  <h:form id="form1">
    <p:dialog id="dialog1">
      <p:commandButton value="Save" action="#{bean.method1}" />   <!-- Working  -->
    </p:dialog>

    <p:dialog id="dialog2">
      <p:commandButton value="Save" action="#{bean.method2}" />   <!--Working  -->
    </p:dialog>
  </h:form>
  <h:form id="form2">
    <!-- ..........  -->
  </h:form>
</ui:composition>

我也遇到过这个问题，在打开浏览器的web控制台后才真正开始研究根本原因。在此之前，我无法获得任何错误消息(即使使用<p:messages>)。web控制台显示从<h:commandButton type="submit" action="#{myBean.submit}">返回的HTTP 405状态码。

在我的例子中，我混合了通过Auth0提供OAuth身份验证的普通HttpServlet和执行应用程序视图和业务逻辑的JSF facet和bean。

一旦我重构了web.xml，并删除了一个中间人servlet，它就“神奇地”工作了。

总之，问题是中间人servlet使用RequestDispatcher.forward(…)从HttpServlet环境重定向到JSF环境，而在此之前调用的servlet使用HttpServletResponse.sendRedirect(…)重定向。

基本上，使用sendRedirect()允许JSF“容器”获得控制，而RequestDispatcher.forward()显然不能。

我不知道为什么facelet能够访问bean属性，但不能设置它们，这显然是为了消除servlet和JSF的混合，但我希望这可以帮助人们避免长时间的头到表的碰撞。