1:59 a.m.
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(a)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(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
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev