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.