Reputation: 4579
I'm debugging a foreign JSF application. The problem is, that I submit a form, but the values aren't carried over.
With a phase listener I can see, that the life cycle doesn't run completely through, so to say it skips phase 2 -5: After the restore view phase, the render response phase is directly called. I miss the apply values, validation, update model actions and so on.
So, this could be a chicken-and-egg problem: 1. The responsible phases aren't called, so the new form input can't be carried over. 2. The system doesn't recognize any new input and therefore directly renders after restoring the view.
I checked that there is no call of responseComplete() oder renderResponse().
I'm stuck somehow. Any idea to validate one of the two hypothesis? Or how to debug that in general? Did anybody have a similar problem?
I have a suspicion, that JSF isn't aware of the postback request and handles this like an initial view. That would explain, that I only pass phase 1 & 6.
How can I check, if JSF recognizes this as a non-faces-request?
How can I check, if there is the appropriate treeID in the current facesContext
.
Upvotes: 4
Views: 3503
Reputation: 4579
Found the solution! I'm sorry but it was very application specific I guess: The custom StateManager for JSF wasn't usable with JSF 1.2. That caused this strange error. Got the StateManager fixed and everything worked fine. That's bitter and cost a lot of time :-(
Thanks for your help anyway :-)
Upvotes: 0
Reputation: 1108722
I'm quoting from an answer I've posted before:
Whenever an
UICommand
component fails to invoke the associated action, verify the following:
UICommand
components must be placed inside anUIForm
component (e.g.h:form
).- You cannot nest multiple
UIForm
components in each other (watch out with include files!).- No validation/conversion error should have been occurred (use
h:messages
to get them all).- If
UICommand
components are placed inside anUIData
component, ensure that exactly the sameDataModel
(the object behind theUIData
'svalue
attribute) is preserved.- The
rendered
anddisabled
attributes of the component and all of the parent components should not evaluate tofalse
during apply request values phase.- Be sure that no
PhaseListener
or anyEventListener
in the request-response chain has changed the JSF lifecycle to skip the invoke action phase.- Be sure that no
Filter
orServlet
in the same request-response chain has blocked the request fo theFacesServlet
somehow.
Since in your particular case the phases 2-5 are been skipped and that you're certain(?) that FacesContext#renderResponse()
isn't been called, the causes 3, 6 and 7 can be scratched from the list. The causes 4 and 5 can likely also be scratched, depending on the way how you debugged the JSF phases. Investigate the other causes. My cents on cause 2. Check if you don't see <form><form></form></form>
in generated HTML source and backtrack this in JSF source.
Upvotes: 7