Clarify purpose of SEVERITY_INFO and SEVERITY_WARN #1035
Comments
|
@glassfishrobot Commented |
|
@glassfishrobot Commented Unfortunately it appears to be quite 'baked in' to the JSF 2.0 internals (eg. now UIInput calls FacesContext.validationFailed as well as FacesContext.responseComplete). So I cannot replicate it for JSF 1.x compatibility. Is there an equivalent to FacesContext.isValidationFailed for JSF 1.x? |
|
@glassfishrobot Commented Regarding a decent definition of the logging levels, that is not something we have considered. While it is true that FacesMessage is a JSF class, when we do consider logging levels, they should be considered at the lowest level of the stack as possible. JavaEE spec section EE.6.2.4.9 explicitly declares the platform spec I'll put a query in to the Titans of JavaEE about this. In the meantime, I do agree with your suggestion that even INFO messages should be considered a validation failure. I'll update the spec accordingly. |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented So this would mean that... if ( context.getMaximumSeverity() != null ) ...is a valid way to test if a validation error has occurred in JSF 1.2? Googling for "getMaximumSeverity() != null" this seems to be used by a few people? Regards, Richard. |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented "... In addition to the default behavior, ensure that any saved per-row state for our child input components is discarded unless it is needed to rerender the current page with errors. ..." There is a check to preserve the model if there is no validation error, looking for no messages with SEVERITY_ERROR. That description comes from JSF 1.1. If an info message is considered a validation error, is this description wrong? I was about to ask if we can change that part to use FacesContext.isValidationFailed for JSF 2.0 and upper, instead of rely on this "weird" logic. |
|
@glassfishrobot Commented If UIData is looking only for SEVERITY_ERROR, then... if ( context.getMaximumSeverity() != null ) ...is not going to cut it. Perhaps the answer would be in understanding why FacesContext.isValidationFailed was introduced? Were people confused about this area? If so, what was the confusion? |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
The severity of a FacesMessages (SEVERITY_INFO, SEVERITY_WARN, SEVERITY_ERROR or SEVERITY_FATAL) is mentioned only once in the JSF spec (section 6.3 FacesMessage). Even then, this is only to enumerate its possible values.
The four severity values are arguably self explanatory, but at least one point would bear some clarification. Specifically: is it still considered a validation error if the severity is INFO?
Section 6.3 descibes all severity values as a 'problem' of some kind ('how serious the problem'). Section 2.2.2 indicates "validations that failed will have caused messages to be enqueued via calls to the addMessage() method". So this does indeed seem to suggest that SEVERITY_INFO (and SEVERITY_WARN) are in fact validation errors - in the sense that they cause the 'Process Validations' lifecycle stage to fail.
Can this be stated explicitly in the spec? The severity names are a bit misleading. I have had users of my widget library question whether SEVERITY_INFO should be considered a validation error. Specifically they have questioned whether...
if ( FacesContext.getCurrentInstance().getMaximumSeverity() != null )
...is a valid way to check for the presence of a validation error.
Affected Versions
[2.1]
The text was updated successfully, but these errors were encountered: