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

Agree. Here is the issue https://hibernate.atlassian.net/browse/BVTCK-63 Thanks, Thang On Thu, Jul 11, 2013 at 2:34 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt;wrote: > 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 > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev