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.
--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