[MYFACES-4123] [per] expensive call on javax.faces.validator.BeanValidator.validate()

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Invalid
• Affects Version/s: 2.0.24, 2.2.12
• Labels: performance
• Assignee: Unassigned
• Reporter: Eduardo Breijo
• Created: 21/Jun/17 20:05
• Updated: 14/Aug/17 16:49
• Resolved: 14/Aug/17 16:49

Description

Currently the javax.faces.validator.BeanValidator.validate() method performs the following check:

        // Initialize Bean Validation.
        ValidatorFactory validatorFactory = createValidatorFactory(context);
        javax.validation.Validator validator = createValidator(validatorFactory, context);
        BeanDescriptor beanDescriptor = validator.getConstraintsForClass(valueBaseClass);
        if (!beanDescriptor.isBeanConstrained())

{             return;         }

       
What we have experienced is that the call to "validator.getConstraintsForClass(valueBaseClass)" is very expensive on the initial call for a particular class. Due to this, the returned BeanDescriptor object is cached by the validator object in some implementations of BeanValidation.
To take advantage of this caching the same validator object needs to be reused. Currently the javax.faces.validator.BeanValidator.validate() creates a new javax.validation.Validator
object with each call. A new validator is necessary to get the correct message interpolator set based upon the current context (the locale is pulled from the FacesContext).
However, for the purposes of checking BeanDescriptor.isBeanConstrained(), the message interpolator does not matter. Therefore, caching a validator object for
the getConstraintsForClass() call should be safe, and greatly improve overall performance.

The only solution I've thought of so far requires an update to the JSF specification that allow for the validator to be stored in the application map under a spec defined key for the sole purpose of the call to getConstraintsForClass. This would be similar to obtaining a validatorFactory where it is stored on the application map under the spec defined VALIDATOR_FACTORY_KEY on the BeanValidator.

It would be interesting if we could come up with an implementation specific way to increase performance in this area or if the only way to fix this is by opening a JSF spec issue.