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(a)hibernate.org>wrote:
2013/6/17 Gunnar Morling <gunnar(a)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/#decor...
> --Gunnar
>
>
>
>
> 2013/6/17 Thang Le <thangmle(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>
>>>
>>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev