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

Emmanuel Bernard emmanuel at hibernate.org
Wed Jan 4 04:49:15 EST 2012


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120104/4a283d28/attachment.html 


More information about the beanvalidation-dev mailing list