HF> Seems everyone is tired of OSGi? Maybe adding the OSGi header is as HF> far as we should go. For the spec, that's the right amount of depth. HF> However, I would like to use this thread to a related question - class loading. HF> At several occasions Hibernate Validator needs to do some class HF> loading or at least needs a class loader (e.g. loading classes HF> specified in the xml configuration, detecting whether JPA is on the HF> classpath in the case of TraversableResolver, loading resource HF> bundles). HF> The spec does not define which class loader should be used in these HF> cases. Hibernate Validator for example first tries the context and HF> then the current class loader. The question is whether there is a HF> need to specify which class loader should be used or should there HF> even be a ClassLoaderService: HF> public interface ClassLoaderService { HF> public <T> Class<T> classForName(String className); HF> // potentially more class loader related methods HF> } HF> An implementation of such a service could be passed if we add HF> HF> javax.validation.Configuration#classLoaderService(ClassLoaderService). This is a more fundamental concern than BV, and I think it should be raised on the JavaEE umbrella JSR list. <http://javaee-spec.java.net> jsr342-experts(a)javaee-spec.java.net. HF> I created https://hibernate.onjira.com/browse/BVAL-286. I really HF> think such a service is beneficial outside the OSGi scope, but even HF> there it is useful. HF> Atm I see two main use cases - loading classes and leading resource HF> bundles HF> <T> Class<T> classForName(String className); HF> ResourceBundle loadBundle(String bundleName, Locale locale); HF> EB> Note that neither your nor my solution differentiate classloading EB> depending on what ought to be loaded. And we also need to consider multi-tenant environments. Perhaps we need to pass in the tennant ID? Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/