[ 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)