As Gerhard is saying, BV 1.1 is integrated with CDI.
So you could also implement your expensive operation in an application
scoped bean which you @Inject into your constraint validator.
For BV 1.0 there is also Seam Validation  (not actively maintained
anymore, though). When using BV with Spring, there is DI support for
validators as well. So I don't think this requires any addition to the BV
bv 1.1 allows to use cdi beans as constraint-validators.
(for bv 1.0 you can use add-ons like the bv module of  or .)
-> you can use any scope you need.
2013/6/12 Thang Le <thangmle(a)gmail.com>
> Hi all,
> I've come across a scenario which makes me think supporting different
> scopes for custom constraint validators would ease the task for writing
> efficient validation logic. Similar to Spring IoC, these scopes are
> prototype, session & singleton. Currently, the Bean Validation 1.1 spec
> suggests a 'prototype' scope should be used for all custom constraint
> validation classes. In my opinion, the 'session' (likely singleton as well)
> scope proves to be useful when a custom constraint validator needs to do
> the SAME timing pre-processing logic before doing some actual validation
> logic on the current targeted object. In such cases, the developer would
> want to store the result of the pre-processing logic into an instance
> variable of the custom constraint validation class and reuse this result
> later when the constraint is executed again on different objects. Below is
> a specific use-case from my current project.
> The model I need to validate has a tree-like structure. In this model,
> each node can be a/an remote/access-point/cluster. I have a model builder
> which builds the model tree given a set of nodes. The builder then hands
> off this tree to the validator to validate it. I have some constraints
> which require to check the uniqueness of a certain property for a set of
> nodes (e.g: all access-points in the tree must have unique serial number).
> These constraints are written as custom constraints. I recognize these
> constraints follow the same pattern which is I need to traverse the tree to
> collect all required node and build a multimap out of the collected nodes
> and check for uniqueness using the key of the current targeted object. For
> above example, the custom constraint is a class constraint of access-point
> class. I need to collect all access-points in the tree, build a multimap of
> <serialNumber:access-point> pairs. Then I lookup from the map the
> collection of access-points based on the serial number of the access-point
> being validated. It would be beneficial if the multimap of
> <serialNumber:access-point> pairs can be stored in the custom validator so
> that I don't need to re-do this expensive task again when validating other
> There might be some reasons that you wouldn't want to support different
> scopes for custom constraint validator. However, I would think when it
> comes to writing a constraint for a bean in relation with other beans, such
> scopes become handy. Please let me know your thoughts on this feature.
> beanvalidation-dev mailing list
beanvalidation-dev mailing list