[jira] [Commented] (MYFACES-4123) Performance improvement needed due to expensive call on javax.faces.validator.BeanValidator.validate()

["Thomas Andraschko (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/MYFACES-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089492#comment-16089492 ] 

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
(v6.4.14#64029)