<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">You mean somebody with an application having the following producer will conflict with the proposal.<div><br></div><div>```</div><div>@Produces</div><div>ValidatorFactory produceValidatorFactory() {...}</div><div>//or</div><div><div>@Produces</div><div>Validator produceValidator() {...}</div></div><div>```</div><div><br></div><div>Is that correct? I am a bit surprised though. Validator and ValidatorFactory are already provided by CDI 1.0 so I imagine a non qualified producer like the on atop would already conflict. Am I right?</div><div><br><div><div>On 4 janv. 2012, at 12:18, Gerhard Petracek wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>that's possible as well (for sure - e.g. myfaces codi (bv-module) already provides such producers), but it can cause compatibility issues with existing applications</div><div>(it won’t be an issue with myfaces codi because it uses a qualifier, but it will be an issue with applications which have to switch from bv 1.0 to 1.1 and have producers without a qualifier).</div>
<div>if we agree on it, we should think about a config entry to deactivate the producer (it would trigger an invocation of ProcessAnnotatedType#veto for the producer).</div><div><br></div><div>in any case: it's still restricted to cdi.</div>
<div><br></div><div>regards,</div><div>gerhard</div><div><br></div><div><br></div><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">Gerhard pointed out a mistake. I mean @Produces or a producer generally. There is no such thing as a @Provider annotation.<div>
<br></div><div>I've got a tangential question. Does CDI have a way to let libraries self declare producers like that? Obviously the BV jar won't be scanned and won't contain a bean.xml?</div><div><div class="h5">
<div><br></div><div><br><div><div><div>On 4 janv. 2012, at 11:19, Emmanuel Bernard wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">The point of Hardy (and Gunnar) is that in a DI environment, the Validator(Factory) lifecycle would most likely be handled by the DI framework and thus that the DI could provide proper injected instance to the BV bootstrap. I have to admit I had not completely seen it that way.<div>
<br></div><div>The BV spec / RI could provide the portable CDI @Provider that implements this logic. For other DIs, they will need to be responsible for it.</div><div><br></div><div>We will see how that plays but in a few ways it requires the DI environment to be aware of the content of validation.xml, we need to prototype that to see if that works well.</div>
<div><br><div><div>On 4 janv. 2012, at 11:13, Gerhard Petracek wrote:</div><br><blockquote type="cite">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" target="_blank">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><font color="#888888"><br>
--Hardy<br>
</font></span><div><div><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><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>
_______________________________________________<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>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></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>
_______________________________________________<br>beanvalidation-dev mailing list<br><a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev<br></blockquote></div><br></div></body></html>