虽然我的答案不是100%适用，但大多数搜索引擎都会把它作为第一个搜索结果，但我还是决定把它贴出来:

如果您正在使用PrimeFaces(或一些类似的API) p:commandButton或p:commandLink，那么您可能忘记显式地将process="@this"添加到命令组件中。

正如PrimeFaces用户指南在3.18节中所述，process和update的默认值都是@form，这与普通JSF f:ajax或RichFaces的默认值截然相反，后者分别是execute="@this"和render="@none"。

只是我花了很长时间才发现。(…而且我认为使用与JSF不同的默认值是相当不聪明的!)

我自己也遇到了这个问题，并发现了这个问题的另一个原因。 如果在支持bean中没有用于*.xhtml中使用的属性的setter方法，则不会调用该操作。

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

简介

每当一个UICommand组件(<h:commandXxx>， <p:commandXxx>，等)调用相关的动作方法失败，或一个UIInput组件(<h:inputXxx>， <p:inputXxxx>，等)失败处理提交的值和/或更新模型值，你不会看到任何googlable异常和/或警告在服务器日志，也不是当你配置一个ajax异常处理按异常处理在JSF ajax请求，也不是当你设置以下上下文参数在web.xml，

<context-param>
    <param-name>javax.faces.PROJECT_STAGE</param-name>
    <param-value>Development</param-value>
</context-param>

你也没有在浏览器的JavaScript控制台中看到任何谷歌错误和/或警告(在Chrome/Firefox23+/IE9+中按F12打开web开发人员工具集，然后打开控制台选项卡)，然后通过以下可能的原因列表进行工作。

可能的原因

UICommand and UIInput components must be placed inside an UIForm component, e.g. <h:form> (and thus not plain HTML <form>), otherwise nothing can be sent to the server. UICommand components must also not have type="button" attribute, otherwise it will be a dead button which is only useful for JavaScript onclick. See also How to send form input values and invoke a method in JSF bean and <h:commandButton> does not initiate a postback. You cannot nest multiple UIForm components in each other. This is illegal in HTML. The browser behavior is unspecified. Watch out with include files! You can use UIForm components in parallel, but they won't process each other during submit. You should also watch out with "God Form" antipattern; make sure that you don't unintentionally process/validate all other (invisible) inputs in the very same form (e.g. having a hidden dialog with required inputs in the very same form). See also How to use <h:form> in JSF page? Single form? Multiple forms? Nested forms?. No UIInput value validation/conversion error should have occurred. You can use <h:messages> to show any messages which are not shown by any input-specific <h:message> components. Don't forget to include the id of <h:messages> in the <f:ajax render>, if any, so that it will be updated as well on ajax requests. See also h:messages does not display messages when p:commandButton is pressed. If UICommand or UIInput components are placed inside an iterating component like <h:dataTable>, <ui:repeat>, etc, then you need to ensure that exactly the same value of the iterating component is been preserved during the apply request values phase of the form submit request. JSF will reiterate over it to find the clicked link/button and submitted input values. Putting the bean in the view scope and/or making sure that you load the data model in @PostConstruct of the bean (and thus not in a getter method!) should fix it. See also How and when should I load the model from database for h:dataTable. If UICommand or UIInput components are included by a dynamic source such as <ui:include src="#{bean.include}">, then you need to ensure that exactly the same #{bean.include} value is preserved during the view build time of the form submit request. JSF will reexecute it during building the component tree. Putting the bean in the view scope and/or making sure that you load the data model in @PostConstruct of the bean (and thus not in a getter method!) should fix it. See also How to ajax-refresh dynamic include content by navigation menu? (JSF SPA). The rendered attribute of the component and all of its parents and the test attribute of any parent <c:if>/<c:when> should not evaluate to false during the apply request values phase of the form submit request. JSF will recheck it as part of safeguard against tampered/hacked requests. Storing the variables responsible for the condition in a @ViewScoped bean or making sure that you're properly preinitializing the condition in @PostConstruct of a @RequestScoped bean should fix it. The same applies to the disabled and readonly attributes of the component, which should not evaluate to true during apply request values phase. See also JSF CommandButton action not invoked, Form submit in conditionally rendered component is not processed, h:commandButton is not working once I wrap it in a <h:panelGroup rendered> and Force JSF to process, validate and update readonly/disabled input components anyway The onclick attribute of the UICommand component and the onsubmit attribute of the UIForm component should not return false or cause a JavaScript error. There should in case of <h:commandLink> or <f:ajax> also be no JS errors visible in the browser's JS console. Usually googling the exact error message will already give you the answer. See also Manually adding / loading jQuery with PrimeFaces results in Uncaught TypeErrors. If you're using Ajax via JSF 2.x <f:ajax> or e.g. PrimeFaces <p:commandXxx>, make sure that you have a <h:head> in the master template instead of the <head>. Otherwise JSF won't be able to auto-include the necessary JavaScript files which contains the Ajax functions. This would result in a JavaScript error like "mojarra is not defined" or "PrimeFaces is not defined" in browser's JS console. See also h:commandLink actionlistener is not invoked when used with f:ajax and ui:repeat. If you're using Ajax, and the submitted values end up being null, then make sure that the UIInput and UICommand components of interest are covered by the <f:ajax execute> or e.g. <p:commandXxx process>, otherwise they won't be executed/processed. See also Submitted form values not updated in model when adding <f:ajax> to <h:commandButton> and Understanding PrimeFaces process/update and JSF f:ajax execute/render attributes. If the submitted values still end up being null, and you're using CDI to manage beans, then make sure that you import the scope annotation from the correct package, else CDI will default to @Dependent which effectively recreates the bean on every single evaluation of the EL expression. See also @SessionScoped bean looses scope and gets recreated all the time, fields become null and What is the default Managed Bean Scope in a JSF 2 application? If a parent of the <h:form> with the UICommand button is beforehand been rendered/updated by an ajax request coming from another form in the same page, then the first action will always fail in JSF 2.2 or older. The second and subsequent actions will work. This is caused by a bug in view state handling which is reported as JSF spec issue 790 and currently fixed in JSF 2.3. For older JSF versions, you need to explicitly specify the ID of the <h:form> in the render of the <f:ajax>. See also h:commandButton/h:commandLink does not work on first click, works only on second click. If the <h:form> has enctype="multipart/form-data" set in order to support file uploading, then you need to make sure that you're using at least JSF 2.2, or that the servlet filter who is responsible for parsing multipart/form-data requests is properly configured, otherwise the FacesServlet will end up getting no request parameters at all and thus not be able to apply the request values. How to configure such a filter depends on the file upload component being used. For Tomahawk <t:inputFileUpload>, check this answer and for PrimeFaces <p:fileUpload>, check this answer. Or, if you're actually not uploading a file at all, then remove the attribute altogether. Make sure that the ActionEvent argument of actionListener is an javax.faces.event.ActionEvent and thus not java.awt.event.ActionEvent, which is what most IDEs suggest as 1st autocomplete option. Having no argument is wrong as well if you use actionListener="#{bean.method}". If you don't want an argument in your method, use actionListener="#{bean.method()}". Or perhaps you actually want to use action instead of actionListener. See also Differences between action and actionListener. Make sure that no PhaseListener or any EventListener in the request-response chain has changed the JSF lifecycle to skip the invoke action phase by for example calling FacesContext#renderResponse() or FacesContext#responseComplete(). Make sure that no Filter or Servlet in the same request-response chain has blocked the request fo the FacesServlet somehow. For example, login/security filters such as Spring Security. Particularly in ajax requests that would by default end up with no UI feedback at all. See also Spring Security 4 and PrimeFaces 5 AJAX request handling. If you are using a PrimeFaces <p:dialog> or a <p:overlayPanel>, then make sure that they have their own <h:form>. Because, these components are by default by JavaScript relocated to end of HTML <body>. So, if they were originally sitting inside a <form>, then they would now not anymore sit in a <form>. See also p:commandbutton action doesn't work inside p:dialog Bug in the framework. For example, RichFaces has a "conversion error" when using a rich:calendar UI element with a defaultLabel attribute (or, in some cases, a rich:placeholder sub-element). This bug prevents the bean method from being invoked when no value is set for the calendar date. Tracing framework bugs can be accomplished by starting with a simple working example and building the page back up until the bug is discovered.

调试提示

如果您仍然被困住了，现在是调试的时候了。在客户端，在web浏览器中按F12打开web开发人员工具集。单击Console选项卡，以便查看JavaScript控制台。它应该没有任何JavaScript错误。下面的截图是一个来自Chrome的例子，它演示了提交一个<f:ajax>启用按钮而没有<h:head>声明的情况(如上面的第7点所述)。

单击Network选项卡查看HTTP流量监视器。提交表单并调查请求头和表单数据以及响应体是否符合预期。下面的截图是一个来自Chrome的例子，它演示了一个成功的ajax提交一个简单的表单与单个<h:inputText>和单个<h:commandButton>与<f:ajax execute="@form" render="@form">。

(警告:当您在生产环境中发布来自HTTP请求头的截图时，请确保您在截图中扰乱/混淆任何会话cookie，以避免会话劫持攻击!)

在服务器端，确保服务器是以调试模式启动的。在JSF组件的方法中放置一个调试断点，您希望在处理表单提交期间调用该方法。例如，对于UICommand组件，那将是UICommand#queueEvent()，而对于UIInput组件，那将是UIInput#validate()。只需逐步执行代码并检查流和变量是否符合预期。下面的截图是一个来自Eclipse调试器的示例。

我最近遇到了一个问题，在使用IBM Extended Faces Components的JSF 1.2应用程序中没有调用uiccommand。

我在数据表的一行上有一个命令按钮(扩展版本，所以<hx:datatable>)， UICommand不会从表中的某些行中触发(不会触发的行是大于默认行显示大小的行)。

我有一个下拉组件，用于选择要显示的行数。支持该字段的值在RequestScope中。支持表本身的数据在某种ViewScope中(实际上，暂时在SessionScope中)。

如果通过绑定到数据表的rows属性的控件来增加行显示，那么在单击此更改后显示的任何行都不能触发UICommand。

将此属性置于与表数据本身相同的作用域中可以解决这个问题。

我认为这在上面的balusc# 4中有所暗示，但不仅表值需要为View或Session范围，而且还需要控制表上显示的行数的属性。

我也遇到过这个问题，在打开浏览器的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的混合，但我希望这可以帮助人们避免长时间的头到表的碰撞。