<div><font color="#222222" face="arial, sans-serif"><div>basically the same which was suggested for the InstanceProvider (we need to agree on the final names but the concept is the same).</div><div>btw. >if< we would like to support @Inject in instances which aren't managed by the container, we also need something like #inject (or #initialize).</div>
<div>-> you can provide e.g. constraint libs which just use @Inject in the constraint validators and there's no need e.g. to configure constraint validators in the container.</div><div><br></div><div>regards,</div>
<div>gerhard</div></font><div><br></div><div><br></div><br><div class="gmail_quote">2012/1/4 Hardy Ferentschik <span dir="ltr"><<a href="mailto:hardy@hibernate.org">hardy@hibernate.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><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>
</div>Can we flesh this out a little. What would be the service interface?<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>