Thomas Andraschko commented on MYFACES-4123:

[~lu4242] WDYT leo?

> Performance improvement needed due to expensive call on 
> javax.faces.validator.BeanValidator.validate()
> ------------------------------------------------------------------------------------------------------
>                 Key: MYFACES-4123
>                 URL: https://issues.apache.org/jira/browse/MYFACES-4123
>             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 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.

This message was sent by Atlassian JIRA

Reply via email to