Sometimes, when using <h:commandLink>, <h:commandButton> or <f:ajax>, the action, actionListener or listener method associated with the tag are simply not being invoked. Or, the bean properties are not updated with submitted UIInput values.
What are the possible causes and solutions for this?
Introduction
Whenever an UICommand component (<h:commandXxx>, <p:commandXxx>, etc) fails to invoke the associated action method, or an UIInput component (<h:inputXxx>, <p:inputXxxx>, etc) fails to process the submitted values and/or update the model values, and you aren't seeing any googlable exceptions and/or warnings in the server log, also not when you configure an ajax exception handler as per Exception handling in JSF ajax requests, nor when you set below context parameter in web.xml,
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
and you are also not seeing any googlable errors and/or warnings in browser's JavaScript console (press F12 in Chrome/Firefox23+/IE9+ to open the web developer toolset and then open the Console tab), then work through below list of possible causes.
Possible causes
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.
Debugging hints
In case you still stucks, it's time to debug. In the client side, press F12 in webbrowser to open the web developer toolset. Click the Console tab so see the JavaScript conosle. It should be free of any JavaScript errors. Below screenshot is an example from Chrome which demonstrates the case of submitting an <f:ajax> enabled button while not having <h:head> declared (as described in point 7 above).
Click the Network tab to see the HTTP traffic monitor. Submit the form and investigate if the request headers and form data and the response body are as per expectations. Below screenshot is an example from Chrome which demonstrates a successful ajax submit of a simple form with a single <h:inputText> and a single <h:commandButton> with <f:ajax execute="#form" render="#form">.
(warning: when you post screenshots from HTTP request headers like above from a production environment, then make sure you scramble/obfuscate any session cookies in the screenshot to avoid session hijacking attacks!)
In the server side, make sure that server is started in debug mode. Put a debug breakpoint in a method of the JSF component of interest which you expect to be called during processing the form submit. E.g. in case of UICommand component, that would be UICommand#queueEvent() and in case of UIInput component, that would be UIInput#validate(). Just step through the code execution and inspect if the flow and variables are as per expectations. Below screenshot is an example from Eclipse's debugger.
If your h:commandLink is inside a h:dataTable there is another reason why the h:commandLink might not work:
The underlying data-source which is bound to the h:dataTable must also be available in the second JSF-Lifecycle that is triggered when the link is clicked.
So if the underlying data-source is request scoped, the h:commandLink does not work!
While my answer isn't 100% applicable, but most search engines find this as the first hit, I decided to post it nontheless:
If you're using PrimeFaces (or some similar API) p:commandButton or p:commandLink, chances are that you have forgotten to explicitly add process="#this" to your command components.
As the PrimeFaces User's Guide states in section 3.18, the defaults for process and update are both #form, which pretty much opposes the defaults you might expect from plain JSF f:ajax or RichFaces, which are execute="#this" and render="#none" respectively.
Just took me a looong time to find out. (... and I think it's rather unclever to use defaults that are different from JSF!)
I would mention one more thing that concerns Primefaces's p:commandButton!
When you use a p:commandButton for the action that needs to be done on the server, you can not use type="button" because that is for Push buttons which are used to execute custom javascript without causing an ajax/non-ajax request to the server.
For this purpose, you can dispense the type attribute (default value is "submit") or you can explicitly use type="submit".
Hope this will help someone!
Got stuck with this issue myself and found one more cause for this problem.
If you don't have setter methods in your backing bean for the properties used in your *.xhtml , then the action is simply not invoked.
I recently ran into a problem with a UICommand not invoking in a JSF 1.2 application using IBM Extended Faces Components.
I had a command button on a row of a datatable (the extended version, so <hx:datatable>) and the UICommand would not fire from certain rows from the table (the rows that would not fire were the rows greater than the default row display size).
I had a drop-down component for selecting number of rows to display. The value backing this field was in RequestScope. The data backing the table itself was in a sort of ViewScope (in reality, temporarily in SessionScope).
If the row display was increased via the control which value was also bound to the datatable's rows attribute, none of the rows displayed as a result of this change could fire the UICommand when clicked.
Placing this attribute in the same scope as the table data itself fixed the problem.
I think this is alluded to in BalusC #4 above, but not only did the table value need to be View or Session scoped but also the attribute controlling the number of rows to display on that table.
I had this problem as well and only really started to hone in on the root cause after opening up the browser's web console. Until that, I was unable to get any error messages (even with <p:messages>). The web console showed an HTTP 405 status code coming back from the <h:commandButton type="submit" action="#{myBean.submit}">.
In my case, I have a mix of vanilla HttpServlet's providing OAuth authentication via Auth0 and JSF facelets and beans carrying out my application views and business logic.
Once I refactored my web.xml, and removed a middle-man-servlet, it then "magically" worked.
Bottom line, the problem was that the middle-man-servlet was using RequestDispatcher.forward(...) to redirect from the HttpServlet environment to the JSF environment whereas the servlet being called prior to it was redirecting with HttpServletResponse.sendRedirect(...).
Basically, using sendRedirect() allowed the JSF "container" to take control whereas RequestDispatcher.forward() was obviously not.
What I don't know is why the facelet was able to access the bean properties but could not set them, and this clearly screams for doing away with the mix of servlets and JSF, but I hope this helps someone avoid many hours of head-to-table-banging.
I had lots of fun debugging an issue where a <h:commandLink>'s action in richfaces datatable refused to fire. The table used to work at some point but stopped for no apparent reason. I left no stone unturned, only to find out that my rich:datatable was using the wrong rowKeyConverter which returned nulls that richfaces happily used as row keys. This prevented my <h:commandLink> action from getting called.
One more possibility: if the symptom is that the first invocation works, but subsequent ones do not, you may be using PrimeFaces 3.x with JSF 2.2, as detailed here: No ViewState is sent.
I fixed my problem with placing the:
<h:commandButton class="btn btn-danger" value = "Remove" action="#{deleteEmployeeBean.delete}"></h:commandButton>
In:
<h:form>
<h:commandButton class="btn btn-danger" value = "Remove" action="#{deleteEmployeeBean.delete}"></h:commandButton>
</h:form>
This is the solution, which is worked for me.
<p:commandButton id="b1" value="Save" process="userGroupSetupForm"
actionListener="#{userGroupSetupController.saveData()}"
update="growl userGroupList userGroupSetupForm" />
Here, process="userGroupSetupForm" atrribute is mandatory for Ajax call. actionListener is calling a method from #ViewScope Bean. Also updating growl message, Datatable: userGroupList and Form: 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>
To solve;
<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>
Related
I'm doing a simple logout and want to make sure i'm referencing correctly to the login root.
<h:form>
<h:commandLink value="Logout" action="#{request.contextPath}/#{userController.logout()}" />
</h:form>
but i get this error:
/topnav.xhtml #16,104 action="#{request.contextPath}/#{userController.logout()}" Not a Valid Method Expression: #{request.contextPath}/#{userController.logout()}
UPDATE
Right now I'm adding navigation rules from the logout link to the login page and since the logout link is on all pages i need to add rules to allow the transition back to the login page. that seems like a lot of configuration for a simple item. would prefer to just have the method called indicate that the login page the the final destination and hot have to place a navigation entry from all pages to the login page.
From the documentation for commandLink:
Name Required Request-time Type
==============================================================
action false false javax.el.MethodExpression
The composite expression #{request.contextPath}/#{userController.logout()} cannot be resolved as a MethodExpression.
The JSF 2.1 specification says of MethodExpressions:
Method expressions are a very similar to value expressions, but rather
than supporting the dynamic retrieval and setting of properties,
method expressions support the invocation (i.e. execution) of an
arbitrary public method of an arbitrary object, passing a specified
set of parameters, and returning the result from the called method (if
any).
try
<h:form>
<h:commandLink value="Logout" action="#{userController.logout()}" />
</h:form>
beside the fact that you do not need context, you can not use # twice the way you are using it.
In my application I am trying to get labels out of a message bundle.
However rather then use constant key values I am using variables
<c:forEach var="emailAddress" items="${emailAddresses}">
...
<c:set var="labelKey" value="Contact_Label_${emailAddress.type}"/>
...
<h:outputText value="#{faces_translations[labelKey]}"/>
...
</c:forEach>
Most of the time this works correctly, but every so often when a page is
loaded some of the label are not processed correctly and the following
message is displayed:
???Contact_Label_???
It looks like the email.type does not return a value, however I added some
debug code to print out the value of email.type by including
${emailAddress.type}
and saw that a value was returned.
Another thing I tried was to remove the value everytime before setting it
again inside the loop using . This resulted in the following
exception. I verified that I had the tag library included in the WAR file
(jstl-api-1.2.jar and jstl-impl-1.2.jar as well as javax.faces-2.1.7).
<c:remove> Tag Library supports namespace: http://java.sun.com/jsp/jstl/core,
but no tag was defined for name: remove
Both these issues are really baffling. The label works most of the time,
but not consistently. The tag is defined in the included library, but cannot be found.
Thanks in advance for any pointers.
JSF UI components and tag handlers like JSTL doesn't run in sync. JSTL runs when the JSF view is to be built. The result is a JSF component tree without any tag handlers like <c:xxx> and <f:xxx>. JSF UI components runs when the JSF view needs to generate HTML for the HTTP response. That very same JSF view can be reused multiple times in subsequent HTTP requests as long as you're interacting with the same view by returning null or void on POST actions (like as you should use a #ViewScoped bean). It is not true that JSTL tags runs on every single HTTP request. That's most likely where it went wrong in your case.
Rather use JSF UI components if you want consistent render-time behaviour while reusing the same view. Your construct can be replaced as follows:
<ui:repeat var="emailAddress" value="#{emailAddresses}">
...
<ui:param name="labelKey" value="Contact_Label_#{emailAddress.type}" />
...
<h:outputText value="#{faces_translations[labelKey]}" />
...
</ui:repeat>
See also:
JSTL in JSF2 Facelets... makes sense?
I have a problem with RichFaces and creating lists of links. If you attempt to use any type of commandLink inside a list (I've tried ui:repeat and rich:list) the action on that link is not called. I've also tried commandButton and the a4j variations of those. I'm using JSF 2, RichFaces 4 on Jboss 6.
<rich:list var="venue" value="#{searchManager.results}" type="definitions" stateVar="status">
<h:form>
<h:commandLink value="CLICK IT" immediate="true" action="#{score.selectVenue}" />
</h:form>
</rich:list>
The position of the form also doesn't matter.
<h:form>
<rich:list var="venue" value="#{searchManager.results}" type="definitions" stateVar="status">
<h:commandLink value="CLICK IT" immediate="true" action="#{score.selectVenue}" />
</rich:list>
</h:form>
If I just have the link by itself (no list) it works.
Any help would be greatly appreciated.
When you click a command link or press a command button to submit a form, JSF will during the apply request values phase scan the component tree for the command link/button in question so that it can find the action expression associated with it, which is in your case #{score.selectVenue}.
However to be able to ever reach that, you would need to ensure that #{searchManager.results} returns exactly the same list as it did when the form was displayed. Because with an empty result list, there would be no command link/button in the view at all during the apply request values phase of the form submit.
Your #{searchManager} bean seems to be request scoped. Request scoped beans have a lifetime of exactly one request-response cycle. So when you submit the form, you'll get a brand new and another instance of the request scoped bean than it was when the form was displayed. The results property seems not to be preserved during (post)construction of the bean and thus remains empty. So JSF cannot find the command link/button in question and thus cannot find the action expression associated with it and thus cannot invoke it.
As you're using JSF2, an easy fix is to place the bean in the view scope. This way the bean will live as long as you're submitting and navigating to exactly the same view by returning null or void in action methods.
#ManagedBean
#ViewScoped
public class SearchManager {
// ...
}
See also:
commandButton/commandLink/ajax action/listener method not invoked or input value not updated
I've got a dropdown on my index.xhtml JSF front page. The associated code/commandButton looks like this:
<h:selectOneMenu id="nodes" value="#{MyBacking.chosenNode}">
<f:selectItems value="#{MyBacking.nodes}" />
</h:selectOneMenu>
<a4j:commandButton value="Retrieve" styleClass="ctrlBtn"
id="retrieveBtn" style="margin-bottom: 2px;"
onclick="#{rich:component('nodeLoadWait')}.show()" # modal
action="#{MyBacking.redirect}"
image="/img/btnRetrieve26.png" />
action was set to 'hello' previously, and in my faces-context.xml:
<navigation-rule>
<from-view-id>/index.xhtml</from-view-id>
<navigation-case>
<from-outcome>hello</from-outcome>
<to-view-id>/nodeMgmt.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
When action was set to 'hello', clicking the retrieve button worked OK in that faces would handle the nav and MyBacking.setChosenNode method would assign all the necessary data, so that the content of nodeMgmt.xhtml would be displayed fully populated.
However, if the initial activity caused by the user clicking retrieve times out, the web page would hang even though the bean detects the time out, and I'd like to redirect the user to a 'timed out' page.
In order to handle the backing bean returning a timedout message (the error detection for which is already present when 'inside' the app), I thought rather than using the faces-context.xml file, I would handle it internally.
I found FacesContext.getCurrentInstance().getExternalContext().redirect but the JSF 1.2 javadoc does not feature this. Perhaps it's because it's not featured? It redirects though which is confusing. Why no documentation on this method?
Nonetheless, it redirects me to the page, but renders without taking into account the data instantiated by the bean during the initial request. The bean is in request scope currently. The relevant code in the bean is
try {
FacesContext.getCurrentInstance().getExternalContext().redirect("nodeMgmt.jsf");
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Is using a backend java call the best way to do this kind of redirection?
If not, is it best to use faces-context.xml? If so, how?
While we're here - can anyone direct me to a good reading resource for FacesContext.getCurrentInstance().getExternalContext() usage which has decent examples about how to do simple navigation with data cos I'm having trouble locating one.
Cheers
I found FacesContext.getCurrentInstance().getExternalContext().redirect but the JSF 1.2 javadoc does not feature this. Perhaps it's because it's not featured? It redirects though which is confusing. Why no documentation on this method?
There certainly is.
JSF 1.1: ExternalContext#redirect()
Java EE 5 (JSF 1.2): ExternalContext#redirect()
Java EE 6 (JSF 2.0): ExternalContext#redirect()
Probably you was reading the wrong javadoc. The one of FacesContext perhaps?
Nonetheless, it redirects me to the page, but renders without taking into account the data instantiated by the bean during the initial request. The bean is in request scope currently.
A redirect instructs the browser to fire a brand new HTTP request. So all request scoped beans from the old request will be garbaged and reinitialized in the new request. If you'd like to retain the request, you'd like to use a forward instead (which JSF by default uses), but this isn't going to work on ajax-initiated requests as it will stick to the same page anyway. Only a response with a redirect will force Ajax to change the window location using JavaScript.
If you want to retain some parameters in the new request, you'd have to pass them as request parameters. E.g.
externalContext.redirect("nodeMgmt.jsf?foo=bar");
and set them as managed property in the bean.
My application has a modal panel where the user can upload files and choose a "document type" in a drop-down select.
I was using an <f:setPropertyActionListener> to set the document type value during the upload event, but sometimes the property is set after the upload has been processed. Probably it's happening because another request is being generated, and this request is handled by another web container thread.
<rich:modalPanel id="attachFiles" autosized="true">
<h:form id="formUpload" enctype="multipart/form-data">
<h:selectOneMenu id="docType" value="#{myMB.docType}" required="true" >
<f:selectItems value="#{myMB.docTypesSelectItems}" />
</h:selectOneMenu>`
<rich:fileUpload id="upload" fileUploadListener="#{myMB.handleUpload}">
<a4j:support event="onupload">
<f:setPropertyActionListener value="#{myMB.docType}"
target="#{myMB.docType}" />
</a4j:support>
</rich:fileUpload>
</rich:modalPanel>
When it happens, the value of myMB.docTypeis null during the execution of myMB.handleUpload, which is not expected, since the field is supposed to be required.
Is there a way to assure that the method myMB.handleUpload is executed only after the property of docType has been set?
I had a similar issue.
Change
<a4j:support event="onupload">
to
<a4j:support event="onclick">
The set document type action will be executed before upload file. Exactly when the explorer file system is opened
<f:setPropertyActionListener value="#{myMB.docType}" target="#{myMB.docType}" />
I don't get you. The target is the same as the value. You're basically setting the target's value with self. Isn't the value itself simply already null?
Anyway, I don't do RichFaces, so I can't go in detail, but I know that it's using Flash under the covers for the upload component and that such a construction usually fires a separate (and standalone) request which doesn't take all other HTML form parameters into account. The "normal" JSF inputs comes thereafter in a separate HTTP request. So you're kind of lost here without bringing in some nasty JS/ajax hacks. At least, in theory.
Your best bet is to get hold of the uploaded file as a bean propery in the listener method and then process that further in the normal bean's action method (the one attached to some UICommand component in the same form).
I would add Ajax capability to the select component instead. This way, the bean value is immediately updated each time the user changes the value of the select. Inside your file uploading method you can then rely on the bean value to represent the most recent selection the user has made.
You would only have to take care of the case, where the user starts the file upload without touching the select. Either you would need to have a sensible default value or you would have to take care of a non-selection and make the select field somehow required before uploading a file.