<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div><div style>--Gunnar</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/13 Thang Le <span dir="ltr"><<a href="mailto:thangmle@gmail.com" target="_blank">thangmle@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Agree. Here is the issue <a href="https://hibernate.atlassian.net/browse/BVTCK-63" target="_blank">https://hibernate.atlassian.net/browse/BVTCK-63</a><div>
<br></div><div>Thanks,</div><div>Thang<div><div class="h5"><br><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Thu, Jul 11, 2013 at 2:34 AM, Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Had I been in your situation, I think I would have written the<br>
uniqueness logic as a plain java code in my service layer instead of<br>
relying on Bean Validation validators. Bean Validation is very much<br>
focused around validating the value at bay (property or class).<br>
<br>
I don't think it makes sense for us to reinvent the wheel and implement<br>
some notion of scope unrelated to CDI. But it might make sense to have<br>
CDI or BV introduce a "validation" scope. Can you open an issue at<br>
<a href="http://beanvalidation.org/issues" target="_blank">http://beanvalidation.org/issues</a><br>
But we will likely need to find other use cases for such scope before it<br>
makes it in the spec.<br>
<span><font color="#888888"><br>
Emmanuel<br>
</font></span><div><div><br>
On Mon 2013-06-17 9:47, Thang Le wrote:<br>
> Thanks, Gunnar for the suggestion.<br>
><br>
> ThreadLocal object is one way to implement the scope for validators.<br>
> However, as you already pointed out, using ThreadLocal introduces a<br>
> different problem where developers need to clean up the data stored in<br>
> local thread. It is not trivial to do it properly. Also, using ThreadLocal<br>
> as a local storage admits an assumption that validation logic is executed<br>
> in a single thread model. This assumption is not mentioned in the BV 1.1<br>
> spec. Hence, it is likely to be broken once future BV spec defines a<br>
> mechanism to allow validating process to be executed in a multi-thread<br>
> model which is a next enhancement I would like to discuss with the group.<br>
><br>
> ThreadLocal or my current solution to this problem is still a personal<br>
> effort to solve a common problem, the scope for constraint validators, of<br>
> bean validation. I would think it is better that we address this common<br>
> problem in the bean validation framework level so that the feature is there<br>
> when a project adopts the framework. Since constrain validators are managed<br>
> by BV module, we can consider BV module is a container for all constraint<br>
> validators. With that in mind, I don't see extending the framework to<br>
> support scopes for constrain validators would introduce a lot of hurdles.<br>
><br>
> Please let me know your thoughts.<br>
><br>
> Thang<br>
><br>
><br>
> On Mon, Jun 17, 2013 at 3:19 AM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>>wrote:<br>
><br>
> > 2013/6/17 Gunnar Morling <<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>><br>
> ><br>
> >> If I understand right, you need some kind of scope which lasts as long as<br>
> >> one validation call.<br>
> >><br>
> >> You could easily implement this yourself using a ThreadLocal object,<br>
> >> either in form of a custom CDI scope or - if you don't want to work with<br>
> >> CDI - using a ThreadLocal object directly within your code.<br>
> >><br>
> >> The only issue is that there is no hook/life cycle event or similar which<br>
> >> could be used to trigger the clean up this scope once validation is over.<br>
> >> For that purpose you could implement a proxy object for<br>
> >> javax.validation.Validator which delegates to the actual validator<br>
> >> implementation but handles the scope management.<br>
> >><br>
> ><br>
> > Minor addition: If you actually decide to use CDI, I think the easiest way<br>
> > for doing the clean up would be via a decorator object for<br>
> > javax.validation.Validator [1] which delegates to the default Validator<br>
> > bean.<br>
> ><br>
> > --Gunnar<br>
> ><br>
> > [1]<br>
> > <a href="http://docs.jboss.org/weld/reference/2.0.1.Final/en-US/html_single/#decorators" target="_blank">http://docs.jboss.org/weld/reference/2.0.1.Final/en-US/html_single/#decorators</a><br>
> ><br>
> ><br>
> >> --Gunnar<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> 2013/6/17 Thang Le <<a href="mailto:thangmle@gmail.com" target="_blank">thangmle@gmail.com</a>><br>
> >><br>
> >>> Hi all,<br>
> >>><br>
> >>> I have done some research along the CDI support in BV 1.1. I agree that<br>
> >>> CDI as described in JSR-299 is a very powerful framework which possibly<br>
> >>> fulfills different needs for scopes of constraint validators. However, I<br>
> >>> feel reluctant to adopt such a complete CDI implementation into my project<br>
> >>> since this adoption is too much for a little gain. Beside scopes for<br>
> >>> constraint validators, all other features described in CDI are redundant<br>
> >>> for my need. Even if I use CDI implementation, I still have to write the<br>
> >>> scope for my constraint validators since there is no built-in scope that<br>
> >>> fits my need. Most of the existing scopes are tailored to use with<br>
> >>> web-beans. There is no built-in scope for object-graph validation scope<br>
> >>> which is what I need.<br>
> >>><br>
> >>> After looking through CDI spec, I am not quite convinced that supporting<br>
> >>> scopes in Bean Validation should be done by CDI module. Since constraint<br>
> >>> validators are created by the bean validation module, would it be better<br>
> >>> that they should have different validation scopes which should also be<br>
> >>> managed by the bean validation module?<br>
> >>><br>
> >>> Thang<br>
> >>><br>
> >>> On Thu, Jun 13, 2013 at 9:29 AM, Thang Le <<a href="mailto:thangmle@gmail.com" target="_blank">thangmle@gmail.com</a>> wrote:<br>
> >>><br>
> >>>> That's great! Let me take a look into this.<br>
> >>>><br>
> >>>> Thanks,<br>
> >>>> Thang<br>
> >>>><br>
> >>>><br>
> >>>> On Thu, Jun 13, 2013 at 2:59 AM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>>wrote:<br>
> >>>><br>
> >>>>> Hi,<br>
> >>>>><br>
> >>>>> As Gerhard is saying, BV 1.1 is integrated with CDI.<br>
> >>>>><br>
> >>>>> So you could also implement your expensive operation in an application<br>
> >>>>> scoped bean which you @Inject into your constraint validator.<br>
> >>>>><br>
> >>>>> For BV 1.0 there is also Seam Validation [1] (not actively maintained<br>
> >>>>> anymore, though). When using BV with Spring, there is DI support for<br>
> >>>>> validators as well. So I don't think this requires any addition to the BV<br>
> >>>>> spec.<br>
> >>>>><br>
> >>>>> --Gunnar<br>
> >>>>><br>
> >>>>> [1] <a href="http://seamframework.org/Seam3/ValidationModule" target="_blank">http://seamframework.org/Seam3/ValidationModule</a><br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> 2013/6/12 Gerhard Petracek <<a href="mailto:gerhard.petracek@gmail.com" target="_blank">gerhard.petracek@gmail.com</a>><br>
> >>>>><br>
> >>>>>> hi thang,<br>
> >>>>>><br>
> >>>>>> bv 1.1 allows to use cdi beans as constraint-validators.<br>
> >>>>>> (for bv 1.0 you can use add-ons like the bv module of [1] or [2].)<br>
> >>>>>><br>
> >>>>>> -> you can use any scope you need.<br>
> >>>>>><br>
> >>>>>> regards,<br>
> >>>>>> gerhard<br>
> >>>>>><br>
> >>>>>> [1] <a href="http://myfaces.apache.org/extensions/cdi/" target="_blank">http://myfaces.apache.org/extensions/cdi/</a><br>
> >>>>>> [2] <a href="http://deltaspike.apache.org" target="_blank">http://deltaspike.apache.org</a><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> 2013/6/12 Thang Le <<a href="mailto:thangmle@gmail.com" target="_blank">thangmle@gmail.com</a>><br>
> >>>>>><br>
> >>>>>>> Hi all,<br>
> >>>>>>><br>
> >>>>>>> I've come across a scenario which makes me think supporting<br>
> >>>>>>> different scopes for custom constraint validators would ease the task for<br>
> >>>>>>> writing efficient validation logic. Similar to Spring IoC, these scopes are<br>
> >>>>>>> prototype, session & singleton. Currently, the Bean Validation 1.1 spec<br>
> >>>>>>> suggests a 'prototype' scope should be used for all custom constraint<br>
> >>>>>>> validation classes. In my opinion, the 'session' (likely singleton as well)<br>
> >>>>>>> scope proves to be useful when a custom constraint validator needs to do<br>
> >>>>>>> the SAME timing pre-processing logic before doing some actual validation<br>
> >>>>>>> logic on the current targeted object. In such cases, the developer would<br>
> >>>>>>> want to store the result of the pre-processing logic into an instance<br>
> >>>>>>> variable of the custom constraint validation class and reuse this result<br>
> >>>>>>> later when the constraint is executed again on different objects. Below is<br>
> >>>>>>> a specific use-case from my current project.<br>
> >>>>>>><br>
> >>>>>>> The model I need to validate has a tree-like structure. In this<br>
> >>>>>>> model, each node can be a/an remote/access-point/cluster. I have a model<br>
> >>>>>>> builder which builds the model tree given a set of nodes. The builder then<br>
> >>>>>>> hands off this tree to the validator to validate it. I have some<br>
> >>>>>>> constraints which require to check the uniqueness of a certain property for<br>
> >>>>>>> a set of nodes (e.g: all access-points in the tree must have unique serial<br>
> >>>>>>> number). These constraints are written as custom constraints. I recognize<br>
> >>>>>>> these constraints follow the same pattern which is I need to traverse the<br>
> >>>>>>> tree to collect all required node and build a multimap out of the collected<br>
> >>>>>>> nodes and check for uniqueness using the key of the current targeted<br>
> >>>>>>> object. For above example, the custom constraint is a class constraint of<br>
> >>>>>>> access-point class. I need to collect all access-points in the tree, build<br>
> >>>>>>> a multimap of <serialNumber:access-point> pairs. Then I lookup from the map<br>
> >>>>>>> the collection of access-points based on the serial number of the<br>
> >>>>>>> access-point being validated. It would be beneficial if the multimap of<br>
> >>>>>>> <serialNumber:access-point> pairs can be stored in the custom validator so<br>
> >>>>>>> that I don't need to re-do this expensive task again when validating other<br>
> >>>>>>> access-points.<br>
> >>>>>>><br>
> >>>>>>> There might be some reasons that you wouldn't want to support<br>
> >>>>>>> different scopes for custom constraint validator. However, I would think<br>
> >>>>>>> when it comes to writing a constraint for a bean in relation with other<br>
> >>>>>>> beans, such scopes become handy. Please let me know your thoughts on this<br>
> >>>>>>> feature.<br>
> >>>>>>><br>
> >>>>>>> Thang<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> _______________________________________________<br>
> >>>>>>> beanvalidation-dev mailing list<br>
> >>>>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> >>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> >>>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> _______________________________________________<br>
> >>>>>> beanvalidation-dev mailing list<br>
> >>>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> >>>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> >>>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> _______________________________________________<br>
> >>>>> beanvalidation-dev mailing list<br>
> >>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> >>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> >>>>><br>
> >>>><br>
> >>>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> beanvalidation-dev mailing list<br>
> >>> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> >>><br>
> >><br>
> >><br>
> ><br>
> > _______________________________________________<br>
> > beanvalidation-dev mailing list<br>
> > <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> ><br>
<br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div></div>
<br>_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br></blockquote></div><br></div>