[bv-dev] BVAL-238 Dependency injection in ConstraintViolation

[Gunnar Morling]

> 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 at 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 at 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/proposals/BVAL-238.md ). 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 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
>