[JAVASERVERFACES_SPEC_PUBLIC-426] Bean Validator support. Created: 14/Jul/08  Updated: 01/Aug/14  Resolved: 24/Nov/09

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 2.0

Type: Improvement Priority: Major
Reporter: alexsmirnov Assignee: Ed Burns
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Attachments: Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt    
Issue Links:
depends on JAVASERVERFACES_SPEC_PUBLIC-428 Clarify zero-length string vs null Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-481 Apply to a validator to a subtree of ... Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-480 Optionally validate all fields includ... Closed
depends on JAVASERVERFACES_SPEC_PUBLIC-482 Ability to specify a default validator Closed
blocks JAVASERVERFACES_SPEC_PUBLIC-52 Umbrella issue for validation issues Closed
Issuezilla Id: 426
Status Whiteboard:



For an annotation-based validation, append "createDefaultValidator" method to an
Application object ( as far as appropriate configuration tags ).
In the base UIInput component, call validate method for a this validator in
addition to a per-component validators.
For a null- or empty values validation, call validator methods for an all
submitted values ( even for an empty or null ).

Comment by pmuir [ 25/Aug/08 ]
  • JSR-303 has the concept of validation groups (such that you can apply only
    certain validations annotations)
  • it should be possible to select which group you are validating from JSF
  • There can be more than one group and a default group should be expected
    (this concept is defined in Bean Validation)
  • the group is just a string
  • you should be able to set the validation group for a group of input
    components e.g.

<f:validate groups="firstscreen">
<h:inputText id="firstname" value="#

{account.firstname}" />
<h:message for="firstname" styleClass="error" />
<h:inputText id="lastname" value="#{account.lastname}" />
<h:message for="lastname" styleClass="error" />
<h:inputText id="cellPhone" value="#{account.cellPhone}" />
<h:message for="cellPhone" styleClass="error" />

- You should also be able to set the group for a single component

<h:inputText id="firstname" value="#{account.firstname}

<f:validate groups="firstscreen" />

  • The only sane solution we could see was to validate against the actual
    populated model. This doesn't work in the current JSF lifecycle, so is probably
    beyond the scope of JSF 2
  • Note that, except for the classical password verification example, most
    cross component validation involve somewhat complex rules that are closer to
    business rules than validations. In the password case, there should be a JSF
  • Should JSR-303 validations be applied by default if a validation annotation is
    present on the property the input component's value expression binds to?
  • Yes
  • How do you disable validation?
  • Explicitly through:

<f:validator disableValidator="true">

  • All validators should be callable via Ajax
  • Client side (JS) validation with no Ajax call. This has some challenges! Some
  • The idea is to avoid any call to the server (less overhead, more responsive)
  • Validators expose some metadata about what they do (e.g. string length,
    number max value). A custom validator can expose a number of pieces of
  • Custom metadata can be exposed
  • metadata is used to attach JS validators to an input component (the
    validator applied in process validations phase may impose extra validation over
    the metadata based JS validator)
  • custom JS validators may be written which are registered and attached for an
    exposed piece of metadata (for example the validator might say it validates
    uk.postcode, in which case the JS validator for uk.postcode would be attached).
    JS validators can be registered in faces-config.xml. Kito says "This sounds like
    it should be an extension of the current validator registration, which means it
    will also be possible to use annotations. The actual JS validator should also
    reference a JSF resource."
  • How to render validation error messages. JSR-303 has a pluggable message
    resolver which can access e.g. contextual information from Web Beans. This isn't
    available on the client, so the proposal is to provide a "safe" message which is
    generated when the page is rendered. The only replacement it can make is for the
    current input value
Comment by Ed Burns [ 09/Sep/08 ]


Comment by Ed Burns [ 15/Oct/08 ]

Change target milestone to 2.0

Comment by Ed Burns [ 26/Feb/09 ]

Created an attachment (id=203)
fix for this bug, merge from branch to trunk

Comment by Ed Burns [ 11/Mar/09 ]

Created an attachment (id=214)
Change to default validator activation.

Comment by Ed Burns [ 12/Mar/09 ]

Created an attachment (id=215)
reset everything back to the way it was.

Comment by Ed Burns [ 26/Mar/09 ]

Created an attachment (id=221)
Fix for performance optimization to not invoke BV unless necessary

Comment by Ed Burns [ 29/Jul/09 ]

take ownership

Comment by Ed Burns [ 29/Jul/09 ]


Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

Generated at Fri Apr 28 18:02:03 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.