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(a)gmail.com&gt; 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(a)hibernate.org&gt; wrote: _______________________________________________ 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

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(a)hibernate.org&gt; 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(a)gmail.com&gt; > >> 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(a)hibernate.org&gt; wrote: >> >> _______________________________________________ >> 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 > > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

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(a)gmail.com&gt; > 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(a)hibernate.org&gt; 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(a)gmail.com&gt; >> >>> 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(a)hibernate.org&gt; wrote: >>> >>> _______________________________________________ >>> 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 >> >> > _______________________________________________ > 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

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(a)hibernate.org&gt; 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(a)gmail.com&gt; > >> 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(a)hibernate.org&gt; wrote: >> >> _______________________________________________ >> 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 > > _______________________________________________ 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