I'm not sure I understood all that. But don't go getting "clever" with the
JSF lifecycle. It will cause you pain now and probably even more pain later.
It is extremely bad practice for validators to do anything that has side effects - that is, changes the JSF or application environment. The insertion or removal of validators should be effectively transparent to the program, except that obviously if you remove the validator, that allows bad data to proceed down the JSF lifecycle pipeline.
I'm even doubtful that
you should be doing web service based validation. I prefer to keep my validators lightweight.
You should
definitely not be coding property setters with side effects. You don't have any real assurance when, or how many times, the setter will be invoked. Even if you sat down and calculated all the various scenarios, it could change in a future JSF release, it's kludgy, and it goes against the spirit of what the setters are supposed to do.
Ideally, all validation could be done by validators. But then again, what you're describing doesn't sound like just validation - it's validation with side effects, and like I said, neither validators not property methods should have side effects. Some things are just better left to the action processors. For the really gnarly stuff, the action processor is the "validator of last resort". If it doesn't like the data, it has the ability to reset the propert(ies), if desired, add an error to the JSF context, and return with a "validation failure" result
string so that the JSF navigator will redisplay the page (or whatever page is most appropriate). Plus, of course, action methods have free rein to invoke any web and/or database services they want, cache data, manipulate data, and, of course, invoke business logic.