Pete Muir commented on CDI-184:
Both JPA and BeanValidation are solving a substantially different problem to
CDI.current(), in that they are about *starting* either JPA or Bean Validation, whilst
CDI.current() is about accessing a *already running* CDI container.
We aren't trying to allow users to "discover the various CDI
implementations" but obtain a link to the currently running CDI container.
Unlike JPA (and possibly BV?), there is no expectation in CDI that you would have more
than one implementation co-exist, nor do I think this would be useful or practical.
We could add a CDI.setCDIProvider(CDIProvider cdiProvider) should would override the
service loader totally I guess.
Make sure that CDI.current() works in a modular environment
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Emmanuel Bernard
Fix For: 1.1 (Proposed)
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
h4. JPA 2's approach
JPA 2 does have a static getter / setter pair
which holds the resolver to use. A modular environment is free to override the default
h4. Bean Validation's approach
Bean Validation uses a different approach to work around the nasty static field.
.providerResolver( myOSGiResolver )
.configure() //we have ways to customize the ValidatorFactory further
Note that Bean VAlidation approach has another benefit, you can physically ask for a
specific Bean Validation provider implementation
.byProvider( HibernateValidator.class )
.ignoreXmlConfiguration() //bean validation configuration
.failSafe() //Hibernate specific configuration (type safe)
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira