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

[Gerhard Petracek]

it's very similar. it's just about using std.java vs. adding an additional
config entry.

+0 for both

regards,
gerhard



2012/1/4 Emmanuel Bernard <emmanuel at hibernate.org>

> That makes sense but what does the ServiceLoder pattern brings to the
> table then compared to option 4 + a field in validation.xml?
>
> On 4 janv. 2012, at 10:46, Gerhard Petracek wrote:
>
> a bv-implementation can use a default implementation (which isn't
> configured -> it gets instantiated manually).
> such a default implementation aggregates the configured versions.
> e.g. if you have cdi + spring in the classpath, only one will return a
> result. as soon as an implementation returns a result, the rest can be
> skipped.
>
> regards,
> gerhard
>
>
>
> 2012/1/4 Michael Nascimento <misterm at gmail.com>
>
>> In most deployment scenarios, I wouldn't expect more than one to be
>> available, so it should simply work. In case more than one is available, we
>> should probably fail with an exception.
>>
>> Regards,
>> Michael
>> On 4 Jan 2012 07:16, "Emmanuel Bernard" <emmanuel at hibernate.org> wrote:
>>
>>> I'm not sure I follow you exact proposal so let me rephrase and let me
>>> know if I am off track.
>>>
>>> You want we define a service loader
>>> http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.htmlto retrieve the expected DI solution.
>>>
>>> My concern with that is that it's a static solution. What happens if two
>>> service providers corresponding to this service are present? Which one to
>>> chose and how is the user expected to chose one or the other?
>>> I feel like we should keep Bean Validation's configuration away from any
>>> "static" approach and let people configure two ValidatorFactory completely
>>> independently.
>>>
>>> On 3 janv. 2012, at 21:55, Gerhard Petracek wrote:
>>>
>>> hi,
>>>
>>> i was going to suggest something similar.
>>>
>>> we could provide a simple adapter interface with a method like:
>>> <T> T resolveBean(Class<T> targetType)
>>>  (and if we would like to support dependent beans, we should think about
>>> an additional dispose method.)
>>>
>>> the only restriction is the manual usage of methods like
>>> ValidatorContext#messageInterpolator.
>>> however, since it would be possible to configure those parts via a
>>> dependency injection container like cdi, it isn't a big issue.
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2012/1/3 Michael Nascimento <misterm at gmail.com>
>>>
>>>> What about a different proposal: looking up the interface
>>>> implementation using ServiceLoader? Then there would be nothing special
>>>> about it.
>>>>
>>>> Regards,
>>>> Michael
>>>> On 3 Jan 2012 17:25, "Emmanuel Bernard" <emmanuel at hibernate.org> wrote:
>>>>
>>>> _______________________________________________
>>>> 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
>
>
>
> _______________________________________________
> 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/20120104/7119eaca/attachment-0001.html