[bv-dev] Scopes support for custom constraint validators

[Thang Le]

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 at 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 at hibernate.org
> >wrote:
> >
> > > 2013/6/17 Gunnar Morling <gunnar at 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 at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
> > >>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> beanvalidation-dev mailing list
> > >>>>>> beanvalidation-dev at lists.jboss.org
> > >>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> beanvalidation-dev mailing list
> > >>>>> beanvalidation-dev at lists.jboss.org
> > >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >>>>>
> > >>>>
> > >>>>
> > >>>
> > >>> _______________________________________________
> > >>> beanvalidation-dev mailing list
> > >>> beanvalidation-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >>>
> > >>
> > >>
> > >
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > > beanvalidation-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >
>
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130712/1517807f/attachment-0001.html