[bv-dev] Scopes support for custom constraint validators

Mon Jun 17 09:47:44 EDT 2013

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130617/e7b3229a/attachment-0001.html 