[bv-dev] Scopes support for custom constraint validators

[Gunnar Morling]

Hi,

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.

--Gunnar

[1] http://seamframework.org/Seam3/ValidationModule



2013/6/12 Gerhard Petracek <gerhard.petracek at gmail.com>

> 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.
>
> regards,
> gerhard
>
> [1] http://myfaces.apache.org/extensions/cdi/
> [2] http://deltaspike.apache.org
>
>
>
> 2013/6/12 Thang Le <thangmle at 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
>> 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.
>>
>> Thang
>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130613/f3594bab/attachment.html