Re: [bv-dev] Scopes support for custom constraint validators

That's great! Let me take a look into this. Thanks, Thang On Thu, Jun 13, 2013 at 2:59 AM, Gunnar Morling <gunnar(a)hibernate.org&gt;wrote: > 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&gt; > >> 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&gt; >> >>> 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 >> > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >