<div><div><div>that isn't true. in case of cdi a cdi enabled archive is required (see beans.xml marker file) and for spring you can e.g. specify the packages which should get scanned and for google guice you create e.g. modules.</div>
<div><br></div><div>in case of a wrong usage your beans would be managed by multiple containers which would be an issue on its own.</div><div><br></div><div>regards,</div><div>gerhard</div></div><div><br></div><div><br><br>
<div class="gmail_quote">2012/1/4 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Every DI can provide you with an instance :) In CDI basically any Java class is a CDI bean and thus can be provided :)<div><div class="h5"><div><br><div><div>On 4 janv. 2012, at 15:22, Gerhard Petracek wrote:</div>
<br><blockquote type="cite"><div><div><div>as mentioned before, we don't need a config to choose the right one. the right one is the one which provides an instance.</div><div><br></div><div>regards,</div><div>gerhard</div>
<div><br></div><br><br><div class="gmail_quote">
2012/1/4 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 4 janv. 2012, at 14:54, Hardy Ferentschik wrote:<br>
<br>
><br>
> On Jan 4, 2012, at 2:31 PM, Gerhard Petracek wrote:<br>
><br>
>> +1 -> compared to the other suggestions: +1 for the service-loader approach because it allows jsr330 support without the need to add a new method to ValidatorContext as well as a new config entry and it's a std. java mechanism.<br>
><br>
> Can we flesh this out a little. What would be the service interface?<br>
<br>
</div>I imagine something similar to the `InstanceProvider` I've proposed.<br>
<br>
But I don't think I agree that a ServiceLoader + a new config to chose the right one is better than a new config pointing to the class + an API to provide the instance in the bootstrap. At least that's not consistent with our treatment of `TraversableResolver`, `MessageInterpolator` and `ConstraintValidatorFactory`. And we know that service loader files (META-INF/services/*) don't play well in modular environments esp OSGi.<br>
<div><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>
</div></div></blockquote></div><br></div></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></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>