http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFIntro10.html
As you can see from the diagram, events are fired pretty much between every stage of the JSF lifecycle, not just before firing the Action Processor.
Unfortunately, they didn't bother to indicate
which events are fired between which stages. Although Phase events happen between about all of them.
The formal specs on what gets done where are in the Sun
J2EE and J33 spec manuals, but they cover the full stack and I couldn't find an HTML reference internally, so I guess you'd have to download the entire PDF. Kito Mann's JSF in Action book also does a fair job of detailing this kind of stuff.
In JSF life cycle, aren't setters supposed to be invoked before any events are fired?
No, setters are invoked just about dead last. The ValueChange events are fired during that blue "Process Events" box right before the Update Model stage.
JSF is extremely protective of the data in its backing beans and lets almost everything else process first, just to make sure that things are just right. The setters are invoked as a
unit - all or nothing, so if anything causes the lifecycle to bypass the Update Data phase, all properties remain unmodified. You don't get halfway into an update and break - at least if you're making proper use of validation services. And all validations are done before value change events, so this ensures that you are working with good, consistent data. Unless you break the rules and muck with them out-of-band. And I refuse to admit whether horrible things have happened to me while I learned that the hard way.
After the model has been updated, then (and only then) is it possible to fire off the action processors. First the action Listeners are invoked, in order of declaration, then the action processsor itself. Either or both of these items are optional.