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.

in case of a wrong usage your beans would be managed by multiple containers which would be an issue on its own.

regards,
gerhard



2012/1/4 Emmanuel Bernard <emmanuel@hibernate.org>
Every DI can provide you with an instance :) In CDI basically any Java class is a CDI bean and thus can be provided :)

On 4 janv. 2012, at 15:22, Gerhard Petracek wrote:

as mentioned before, we don't need a config to choose the right one. the right one is the one which provides an instance.

regards,
gerhard



2012/1/4 Emmanuel Bernard <emmanuel@hibernate.org>

On 4 janv. 2012, at 14:54, Hardy Ferentschik wrote:

>
> On Jan 4, 2012, at 2:31 PM, Gerhard Petracek wrote:
>
>> +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.
>
> Can we flesh this out a little. What would be the service interface?

I imagine something similar to the `InstanceProvider` I've proposed.

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.
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev