hi hardy,<div><br></div><div>you won't get dependency injection support with manual bootstrapping (btw. you would have to use the class of a >concrete< cdi implementation - and that isn't portable).</div><div>
with the service-loader approach a new method for ValidatorContext is also optional.</div><div><br></div><div>regards,</div><div>gerhard</div><div><br></div><div><br><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">Hi,<br>
<br>
I prefer option 3 for its simplicity and the fact that it does not change the current bootstrap API.<br>
As you already say, integration is completely managed by the CDI-side in which case I don't see why it<br>
CDI could not manage MessageInterpolator and TraversableResolver as well.<br>
<br>
I also think that Gunnar has a point that introducing InstanceProvider creates some confusion with<br>
the existing API. I also agree that CDI should know about BV, but not the other way around.<br>
<span class="HOEnZb"><font color="#888888"><br>
--Hardy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Jan 3, 2012, at 8:25 PM, Emmanuel Bernard wrote:<br>
> #### Option 1: Add a Method to inject the BeanManager instance on Bean Validation bootstrap sequence<br>
><br>
> One approach would be to let the container set a `BeanManager` instance<br>
><br>
> ValidatorFactory factory = Validation<br>
> .byDefaultProvider()<br>
> .configure()<br>
> .cdiBeanManager(beanManager)<br>
> .buildValidatorFactory();<br>
><br>
> However that would add a hard dependency between CDI and Bean Validation which is probably not welcomed.<br>
><br>
> An alternative is to use an untyped version (which should probably be favored):<br>
><br>
><br>
> ValidatorFactory factory = Validation<br>
> .byDefaultProvider()<br>
> .configure()<br>
> // T cdiBeanManager(Object beanManager) //raises an exception if that's not a BeanManager<br>
> .cdiBeanManager(beanManager)<br>
> .buildValidatorFactory();<br>
><br>
><br>
> vs<br>
><br>
> ValidatorFactory factory = Validation<br>
> .byDefaultProvider()<br>
> .configure()<br>
> //raises an exception if that's not a BeanManager<br>
> .addObject(Validation.CDI_BEAN_MANAGER, beanManager) // T addObject(String key, Objet value)<br>
> .buildValidatorFactory();<br>
><br>
> I however feel chagrined that the nicely typed `Configuration` API requires such untyped approach.<br>
> (I don't think introducing CdiBeanManagerFactory solves any issue, is that true?).<br>
><br>
><br>
> - have an untyped version of the above proposal<br>
> - offer a generic `Map<String,Object> addObject(String key, Object value)` method on `Configuration`<br>
><br>
> #### Option 2: Use CDI facility to retrive the current `BeanManager`<br>
><br>
> CDI exposes `BeanManager` via JNDI in EE, we could use it.<br>
><br>
> Also CDI 1.1 offers programmatic lookup via the CDI class, see EDR1 spec for details.<br>
> <<a href="http://docs.jboss.org/cdi/spec/1.1.EDR1/html/spi.html#provider" target="_blank">http://docs.jboss.org/cdi/spec/1.1.EDR1/html/spi.html#provider</a>><br>
><br>
> #### Option 3: Ask CDI to inject a CDI aware `ConstraintValidatorFactory` when creating the `ValidatorFactory` object<br>
><br>
> Another idea would be to integrate BV/CDI via a CDI-aware `ConstraintValidatorFactory` to be provided by CDI runtimes:<br>
><br>
> ValidatorFactory factory = Validation<br>
> .byDefaultProvider()<br>
> .configure()<br>
> .constraintValidatorFactory( new CdiAwareConstraintValidatorFactory( beanManager ) )<br>
> .buildValidatorFactory();<br>
><br>
> That way the integration is completely managed by the CDI-side. `Validator` and `ValidatorFactory` are already<br>
> built-in beans in CDI so this wouldn't add much complexity.<br>
> The CDI runtime would use this factory whenever a `Validator` or `ValidatorFactory` is retrieved.<br>
><br>
> #### Option 4: Add a method accepting an `InstanceProvider` implementation in Bean Validation's bootstrap<br>
><br>
> ValidatorFactory factory = Validation<br>
> .byDefaultProvider()<br>
> .configure()<br>
> .instanceProvider(cdiInstanceProvider)<br>
> .buildValidatorFactory();<br>
><br>
> public interface InstanceProvider {<br>
> public <T> T createInstance(Class<T> type);<br>
> public destroyInstance(Object instance);<br>
> }<br>
><br>
> The default implementation can be the no-arg constructor we have today. We can either ask CDI to<br>
> provide a `CDIInstanceProvider` at `ValidatorFactory` creation like in option 3 or make it the<br>
> default implementation if CDI is present according to option 2.<br>
><br>
> This option works fine as long as we don't require more complex object creation logic.<br>
><br>
<br>
<br>
</div></div><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>