EB> On 14 mai 2012, at 21:06, Gunnar Morling wrote: EB> Should the application developer write a module that will bootstrap EB> Bean Validation? That the thing I want to avoid, having the user do EB> useless heavy lifting. HF> In the end it is up to the framework providers to make it as simple HF> as possible to use Bean Validation for modules/apps running within HF> the framework. All Bean Validation needs to provide is a way to set HF> the class loader. Speaking on behalf of the provider of the JSF framework (a BV consuming technology), I think I want the BV spec to say something like, "Implementations must do X and Y and then a ValidatorFactory will be available." I am fine if X and Y are expressed in terms of OSGi APIs. GM> a) The user indeed bootstraps BV (passing the class loader) and GM> registers VF as OSGi service. This would be done using a bundle GM> activator roughly like that: GM> b) The BV provider's OSGi bundle performs the registration of the VF. GM> The required class loader would be provided via a ClassLoaderService, GM> for which the user has to register an implementation in his activator: If a) obviates the need for the whole icky (and really not appropriately located (see below)) ClassLoader service, I'd rather have a). Yes, it's more code, but it's code the container vendor writes once. In the end, Oracle's containers use HVAL anyway. Eddie> This is a more fundamental concern than BV, and I think it should be Eddie> raised on the JavaEE umbrella JSR list. <http://javaee-spec.java.net> Eddie> jsr342-experts(a)javaee-spec.java.net. I'd really like to not have a ClassLoader service in a (sub-) package javax.validation. If anything, javax.enterprise.util seems a better home. Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/