tags:

views:

268

answers:

2

Hey fellows,

I have to debug a foreign jsf application thanks god. 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?


Update

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.

+2  A: 

I'm quoting from an answer I've posted before:

Whenever an UICommand component fails to invoke the associated action, verify the following:

  1. UICommand components must be placed inside an UIForm component (e.g. h:form).
  2. You cannot nest multiple UIForm components in each other (watch out with include files!).
  3. No validation/conversion error should have been occurred (use h:messages to get them all).
  4. If UICommand components are placed inside an UIData component, ensure that exactly the same DataModel (the object behind the UIData's value attribute) is preserved.
  5. The rendered and disabled attributes of the component and all of the parent components should not evaluate to false during apply request values phase.
  6. Be sure that no PhaseListener or any EventListener in the request-response chain has changed the JSF lifecycle to skip the invoke action phase.
  7. Be sure that no Filter or Servlet in the same request-response chain has blocked the request fo the FacesServlet 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.

BalusC
Thank you, I'll check that. Other ideas are still welcome :-)
Peter Wippermann
First let know if you've excluded everything.
BalusC
I checked everything. Doesn't seem to be an error with the application itself, but with the Server/JSF/Configuration in general. I don't know, what could have got broken there.
Peter Wippermann
Are you using `binding` attribute anywhere in JSF page? If so, did you ensure that they each points to their own property (and thus doesn't share the other's)?
BalusC
The only appearance of binding is the following: <f:subview id="aktuelleVorgaengeListe" binding="#aktuelleVorgaengeBB.aktuelleVorgaengeSubview}"> <%@include file="fragment/AktuelleVorgangsListeFragment.jsp"%></f:subview>I'm sorry, but I don't understand where the problem might be.
Peter Wippermann
Please also see my update above.
Peter Wippermann
`@include`? Rather use `<jsp:include>`. That could also be the cause. Next step would be checking the generated HTML output if all is right and checking the request headers/body during the form submit.
BalusC
A: 

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 :-)

Peter Wippermann