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.--Gunnar2013/7/13 Thang Le <thangmle@gmail.com>
Agree. Here is the issue https://hibernate.atlassian.net/browse/BVTCK-63Thanks,Thang
On Thu, Jul 11, 2013 at 2:34 AM, Emmanuel Bernard <emmanuel@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@hibernate.org>wrote:
>
> > 2013/6/17 Gunnar Morling <gunnar@hibernate.org>
> >
> >> 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/#decorators
> >
> >
> >> --Gunnar
> >>
> >>
> >>
> >>
> >> 2013/6/17 Thang Le <thangmle@gmail.com>
> >>
> >>> 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@gmail.com> 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@hibernate.org>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@gmail.com>
> >>>>>
> >>>>>> 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@gmail.com>
> >>>>>>
> >>>>>>> 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@lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> beanvalidation-dev mailing list
> >>>>>> beanvalidation-dev@lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> beanvalidation-dev mailing list
> >>>>> beanvalidation-dev@lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>>>
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> beanvalidation-dev mailing list
> >>> beanvalidation-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>
> >>
> >>
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev