[bv-dev] Scopes support for custom constraint validators
Gunnar Morling
gunnar at hibernate.org
Mon Jul 15 03:58:15 EDT 2013
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 at gmail.com>
> 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
>>
>
>
> _______________________________________________
> 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/20130715/67e97fcd/attachment-0001.html
More information about the beanvalidation-dev
mailing list