In a good chunk of deployments I can see both the CDI impl of the EE container and Spring Framework be present. I don't want that to throw an exception :) Hell, we might have an OSGIInstanceProvider thrown in.

On 4 janv. 2012, at 10:39, Michael Nascimento wrote:

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@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@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@hibernate.org> wrote:

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev