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

Had I been in your situation, I think I would have written the uniqueness logic as a plain java code in my service layer instead of relying on Bean Validation validators. Bean Validation is very much focused around validating the value at bay (property or class). I don't think it makes sense for us to reinvent the wheel and implement some notion of scope unrelated to CDI. But it might make sense to have CDI or BV introduce a "validation" scope. Can you open an issue at http://beanvalidation.org/issues But we will likely need to find other use cases for such scope before it makes it in the spec. Emmanuel On Mon 2013-06-17 9:47, Thang Le wrote: > Thanks, Gunnar for the suggestion. > > ThreadLocal object is one way to implement the scope for validators. > However, as you already pointed out, using ThreadLocal introduces a > different problem where developers need to clean up the data stored in > local thread. It is not trivial to do it properly. Also, using ThreadLocal > as a local storage admits an assumption that validation logic is executed > in a single thread model. This assumption is not mentioned in the BV 1.1 > spec. Hence, it is likely to be broken once future BV spec defines a > mechanism to allow validating process to be executed in a multi-thread > model which is a next enhancement I would like to discuss with the group. > > ThreadLocal or my current solution to this problem is still a personal > effort to solve a common problem, the scope for constraint validators, of > bean validation. I would think it is better that we address this common > problem in the bean validation framework level so that the feature is there > when a project adopts the framework. Since constrain validators are managed > by BV module, we can consider BV module is a container for all constraint > validators. With that in mind, I don't see extending the framework to > support scopes for constrain validators would introduce a lot of hurdles. > > Please let me know your thoughts. > > Thang > > > On Mon, Jun 17, 2013 at 3:19 AM, Gunnar Morling <gunnar(a)hibernate.org >wrote: > > > 2013/6/17 Gunnar Morling <gunnar(a)hibernate.org&gt; > > > >> If I understand right, you need some kind of scope which lasts as long as > >> one validation call. > >> > >> You could easily implement this yourself using a ThreadLocal object, > >> either in form of a custom CDI scope or - if you don't want to work with > >> CDI - using a ThreadLocal object directly within your code. > >> > >> The only issue is that there is no hook/life cycle event or similar which > >> could be used to trigger the clean up this scope once validation is over. > >> For that purpose you could implement a proxy object for > >> javax.validation.Validator which delegates to the actual validator > >> implementation but handles the scope management. > >> > > > > Minor addition: If you actually decide to use CDI, I think the easiest way > > for doing the clean up would be via a decorator object for > > javax.validation.Validator [1] which delegates to the default Validator > > bean. > > > > --Gunnar > > > > [1] > > http://docs.jboss.org/weld/reference/2.0.1.Final/en-US/html_single/#decor... > > > > > >> --Gunnar > >> > >> > >> > >> > >> 2013/6/17 Thang Le <thangmle(a)gmail.com&gt; > >> > >>> Hi all, > >>> > >>> I have done some research along the CDI support in BV 1.1. I agree that > >>> CDI as described in JSR-299 is a very powerful framework which possibly > >>> fulfills different needs for scopes of constraint validators. However, I > >>> feel reluctant to adopt such a complete CDI implementation into my project > >>> since this adoption is too much for a little gain. Beside scopes for > >>> constraint validators, all other features described in CDI are redundant > >>> for my need. Even if I use CDI implementation, I still have to write the > >>> scope for my constraint validators since there is no built-in scope that > >>> fits my need. Most of the existing scopes are tailored to use with > >>> web-beans. There is no built-in scope for object-graph validation scope > >>> which is what I need. > >>> > >>> After looking through CDI spec, I am not quite convinced that supporting > >>> scopes in Bean Validation should be done by CDI module. Since constraint > >>> validators are created by the bean validation module, would it be better > >>> that they should have different validation scopes which should also be > >>> managed by the bean validation module? > >>> > >>> Thang > >>> > >>> On Thu, Jun 13, 2013 at 9:29 AM, Thang Le <thangmle(a)gmail.com&gt; wrote: > >>> > >>>> 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 > >>>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> 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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev