Details
-
Feature Request
-
Resolution: Done
-
Major
-
None
-
None
-
None
Description
OSGi containers and other modular environments tend to hide service files and consider them implementation details. That means that a naive current classloader based implementation won't discover the various CDI implementations.
There are several approaches to try and work around this problem in EE specs
JPA 2's approach
JPA 2 does have a static getter / setter pair
PersistenceProviderResolverHolder.getPersistenceProviderResolver() PersistenceProviderResolverHolder.setPersistenceProviderResolver()
which holds the resolver to use. A modular environment is free to override the default resolver.
Bean Validation's approach
Bean Validation uses a different approach to work around the nasty static field.
Validation
.byDefaultProvider()
.providerResolver( myOSGiResolver )
.configure() //we have ways to customize the ValidatorFactory further
.buildValidatorFactory();
Note that Bean VAlidation approach has another benefit, you can physically ask for a specific Bean Validation provider implementation
Validation .byProvider( HibernateValidator.class ) .configure() .ignoreXmlConfiguration() //bean validation configuration .failSafe() //Hibernate specific configuration (type safe) .buildValidatorFactory();