So this is a headache because I'm working with other people's code and so I'm not as familiar with their work as I would like... In any case, we have component values not being updated in one of the view pages, and I'm trying to determine why. I've added a phase listener to dump the component tree to standard output after each phase, and I noticed something odd...
beforePhase() pe.getPhaseId() = RESTORE_VIEW 1
After Phase RESTORE_VIEW 1
This is the entirety of the output when clicking a button on a page with a number of components, including an inputTextarea (which is supposed to receive the updated value). This tree prints out in the afterPhase() method.
EDIT: Using Mojarra 2.0 with PrimeFaces 3.5
So this tells me that not only is the component tree not being fully built, the lifecycle halts after the afterPhase() method runs for the Restore View phase. Mind you, this is not from the initial page render, where I'd only expect to see Restore View and Render Response. This is from clicking a commandButton. The actionListener works, and runs the associated code in the backing bean, so it must be going at least through the Invoke Application phase, and yet this is all the output I see.
Now, what I'm dreading is going through this app, page by page, not sure what I'm looking for so I'm hoping that this will spark some insight among the more experienced folks here.
If people have been meddling with the JSF internals, all bets are off. If, however, this is POJO-style code you're working with, perhaps I can help.
First of all, since you are meddling with JSF internals (PhaseListener), I trust you didn't override a lifecycle method and then forget to pass control back to the mainstream code!
In general, you shouldn't have to be looking at JSF's insides that closely. Usually you can trust everything to "just work". Of course, custom tag renderers might fail, but you can diagnose them at the component level without having to dump the entire component tree.
So if the lifecycle is truly halting, and it's not just some View control that's inhibiting large chunks of rendering, something is probably throwing an exception. The most likely one that comes to mind is OutOfMemory, but that one tends to be pretty obvious. More insidious would be an Exception in custom code that gets eaten instead of reported, which should be a punishable offense. For that sort of problem, I'm glad that my debugger can be set to catch such things.
Customer surveys are for companies who didn't pay proper attention to begin with.