<div><div><div>a bv-implementation can use a default implementation (which isn't configured -> it gets instantiated manually).</div><div>such a default implementation aggregates the configured versions.</div><div>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.</div>
<div><br></div><div>regards,</div><div>gerhard</div></div><div><br></div><div><br></div><div><br><div class="gmail_quote">2012/1/4 Michael Nascimento <span dir="ltr"><<a href="mailto:misterm@gmail.com">misterm@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>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.</p>
<p>Regards,<br>
Michael</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 4 Jan 2012 07:16, "Emmanuel Bernard" <<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">I'm not sure I follow you exact proposal so let me rephrase and let me know if I am off track.<div><br></div><div>You want we define a service loader <a href="http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html" target="_blank">http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html</a> to retrieve the expected DI solution.</div>
<div><br></div><div>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?</div>
<div>I feel like we should keep Bean Validation's configuration away from any "static" approach and let people configure two ValidatorFactory completely independently.</div><div><br><div><div>On 3 janv. 2012, at 21:55, Gerhard Petracek wrote:</div>
<br><blockquote type="cite">hi,<div><br></div><div>i was going to suggest something similar.</div><div><br></div><div>we could provide a simple adapter interface with a method like:</div><div><T> T resolveBean(Class<T> targetType)</div>
<div>
(and if we would like to support dependent beans, we should think about an additional dispose method.)</div><div><br></div><div>the only restriction is the manual usage of methods like ValidatorContext#messageInterpolator.</div>
<div>however, since it would be possible to configure those parts via a dependency injection container like cdi, it isn't a big issue.</div><div><br></div><div>regards,</div><div>gerhard</div><div><br></div><div><br>
</div>
<div><br><div class="gmail_quote">2012/1/3 Michael Nascimento <span dir="ltr"><<a href="mailto:misterm@gmail.com" target="_blank">misterm@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>What about a different proposal: looking up the interface implementation using ServiceLoader? Then there would be nothing special about it.</p><p>Regards,<br>
Michael</p>
<div class="gmail_quote">On 3 Jan 2012 17:25, "Emmanuel Bernard" <<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>> wrote:<br type="attribution"></div>
<br>_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>beanvalidation-dev mailing list<br><a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</blockquote></div><br></div></div><br>_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br></blockquote></div>
</div></div><br>_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br></blockquote></div><br></div></div>