[
https://issues.apache.org/jira/browse/MYFACES-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125955#comment-16125955
]
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: 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
(v6.4.14#64029)
