3:26 p.m.
What you're saying is that assuming @ValidatorFactory is injected
in EE or SE, it is the CDI responsibility to set the right ConstraintValidatorFactory. We
can consider this approach definitely. Can you add it as an alternative in the website
page?
Sure. Can you provide me with write access for the beanvalidation.org repo?
Note that CDI strategy is to let other specs describe their
integration, we are responsible for describing how that will work.
I see. Validator and ValidatorFactory are built-in beans in CDI 1.0
already, so I think one could extend on that and require that the
runtime must use a CDI-enabled ConstraintValidatorFactory. Maybe this
is something which we could contribute to CDI 1.1.
It would be interesting to know how CDI integration is solved for JPA
entity listeners. Do you have any information on that?
2011/10/24 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> There are a couple of reasons why I proposed this approach. Of course nothing i
settled.
>
> - IFAIR, BeanManager was to be responsible from the creation and destruction of the
object. We do have a hook for creation but not for destruction yet. So it's likely
that ConstraintValidatorfactory needs to be enhanced
> - I was trying to facilitate the work of the container or the "SE"
container.
>
What you're saying is that assuming @ValidatorFactory is injected
in EE or SE, it is the CDI responsibility to set the right ConstraintValidatorFactory. We
can consider this approach definitely. Can you add it as an alternative in the website
page?
>
Note that CDI strategy is to let other specs describe their
integration, we are responsible for describing how that will work.
>
> Emmanuel
>
> On 22 oct. 2011, at 10:51, Gunnar Morling wrote:
>
>> Hi,
>>
>> concerning "How is CDI BeanManager (or equivalent) injected into Bean
>> Validation?" I'm wondering whether we really require something like
>> cdiBeanManager().
>>
>> Couldn't the CDI runtime just set a CDI-aware
>> ConstraintValidatorFactory when creating the Validator(Factory). We
>> then wouldn't have any dependency to CDI in BV at all. On the downside
>> this would mean CDI-enabled validators would only work when using a
>> validator managed by CDI but not using a validator retrieved via
>> Validation.buildDefaultValidatorFactory() but that would be ok IMO.
>>
>> So generally I think the BV/CDI integration should be more
>> triggered/managed from the CDI side than the other way around.
>>
>> --Gunnar
>>
>>
>> 2011/10/21 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>> Hi team,
>>> I've been thinking about BVAL-238 and came up with a first round of ideas
and open questions.
>>> It is available here http://beanvalidation.org/proposals/BVAL-238/
>>>
>>> Please give me your feedback. I think this issue can be closed quite
quickly.
>>>
>>> I've also created a proposals section on the website that will contain
such work in progress proposals before inclusion in the spec proper. Check out
http://beanvalidation.org/proposals
>>>
>>> On a side note, for casual website editing, you can use GitHub's `Edit
this file` button (see
https://github.com/beanvalidation/beanvalidation.org/blob/master/proposal... ).
It's not quite a wiki but that's pretty close. One thing you cannot do is create a
new file unfortunately. Anyone that have asked for write access should see this button.
>>>
>>> Emmanuel
>>> _______________________________________________
>>> 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
>