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

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

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

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

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

I'm not sure whether such a feature would pull its weight. I still think you'd be best off just using a @RequestScoped bean to manage your shared state or a simple custom scope or similar facility as discussed above. As you say this wouldn't work if a BV implementation parallelizes validate() calls internally, but at least the RI isn't doing this atm. and I'm wondering whether it ever will. I think the problem is to find a threshold where the benefit of parallelization out-weighs its overhead which may depend on the used system, the validated model and many other things. If you have a huge model where validation in a single call takes "too long", you still might consider validating sub-graphs in parallel, of course you'd have to propagate your shared context yourself in this case. --Gunnar 2013/7/13 Thang Le <thangmle(a)gmail.com&gt; > 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 > > 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 > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev