Using a bean method to perform validation via the validator attribute

Question

The J2EE tutorial demonstrates a method to perform validation by adding a FacesMessage directly into the FacesContext ... INSTEAD OF throwing a ValidatorException within the method:
http://docs.oracle.com/javaee/6/tutorial/doc/bnavb.html#bnave
http://docs.oracle.com/javaee/6/tutorial/doc/bnatn.html#bnatr
What is NOT mentioned in the tutorials is that, if you simply add a FacesMessage into the FacesContext, the JSF lifecycle UPDATE_MODEL and INVOKE_APPLICATION are still executed even if the validation fails, which is probably not what one intends to happen if the validation fails.
Instead of simply adding a FacesMessage into the FacesContext, the method performing the validation should instead throw a ValidatorException(FacesMessage) or ValidatorException(Collection<FacesMessage>), so that the UPDATE_MODEL and INVOKE_APPLICATION are NOT executed and you go directly to RENDER_RESPONSE if the validation fails.
Does anyone see any reason why the tutorial would add the FacesMessage into the FacesContext instead of throwing a ValidatorException ?

Answer 1

gimbal2 wrote:
The whole intention of that section seems to be to give an alternative to using a validator. Its the type of validation I tend to use to be honest since I find it the least cumbersome. I agree with you on this one.
gimbal2 wrote:
I've hardly ever had any trouble with the extra phases happening... but .. isn't the whole point of PROCESS_VALIDATION lifecycle is to prevent updates to the model when the validation fails ... to skip straight to RENDER_RESPONSE ? I just don't see the point of having the validation failing ( by showing an error to the user ), and yet allowing the "illegal" value updated on the model / bean.
On a different matter ... I am still not sure how the JSR-303 validation fits in to the JSF lifecycle with regards to updating the model / bean. If you were using JSR-303 validations WITHOUT JSF, like so:
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();
Set<ConstraintViolation<Bean>> constraintViolations = validator.validate(bean);.. the bean would have been updated already with the "illegal" values for the JSR-303 validation to work / "detect" that validation fails. Now going back to JSR-303 with JSF, that would suggest that model gets updated before the validation takes place ( to mimic the non-JSF validation above ) ... but that can't be the case as nowhere in the JSF / J2EE documentation ( unless I missed it ) that says that UPDATE_MODEL takes place before PROCESS_VALIDATION only if JSR-303 is used. The JSF lifecycle diagrams always say PROCESS_VALIDATION takes place before UPDATE_MODEL, and only if validation succeeds.
On the other hand, JBoss' <rich:graphValidator> is clearly documented so that it actually clones the bean and then updates the properties on the clone of the bean, not the bean itself. Hence, the bean must implement the Cloneable interface. ( http://docs.jboss.org/richfaces/4.2.X/4.2.2.Final/Component_Reference/en-US/html/chap-Component_Reference-Validation.html#sect-Component_Reference-Validation-richgraphValidator ). Okay, that link is saying that the use case for <rich:graphValidator> is for cross-field validation, but at least it documents that the model is not updated.