That's great! Let me take a look into this.


On Thu, Jun 13, 2013 at 2:59 AM, Gunnar Morling <> wrote:

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 [1] (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 spec.



2013/6/12 Gerhard Petracek <>
hi thang,

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 [1] or [2].)

-> you can use any scope you need.


2013/6/12 Thang Le <>
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 access-points.

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

beanvalidation-dev mailing list