myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eduardo Breijo (JIRA)" <>
Subject [jira] [Commented] (MYFACES-4123) [per] expensive call on javax.faces.validator.BeanValidator.validate()
Date Mon, 14 Aug 2017 16:49:00 GMT


Eduardo Breijo commented on MYFACES-4123:

I couldn't find anything in the specs. However, we have found that the latest Apache bean
validation version (1.1.2 vs current 1.1.0) has solved this performance issue by caching the
proper data. I think we can close this issue as invalid. 

> [per] expensive call on javax.faces.validator.BeanValidator.validate()
> ----------------------------------------------------------------------
>                 Key: MYFACES-4123
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Improvement
>    Affects Versions: 2.0.24, 2.2.12
>            Reporter: Eduardo Breijo
>              Labels: performance
> Currently the javax.faces.validator.BeanValidator.validate() method performs the following
>         // Initialize Bean Validation.
>         ValidatorFactory validatorFactory = createValidatorFactory(context);
>         javax.validation.Validator validator = createValidator(validatorFactory,
>         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.

This message was sent by Atlassian JIRA

View raw message