[cdi-dev] [JBoss JIRA] (CDI-184) Make sure that CDI.current() works in a modular environment

[Pete Muir (JIRA)]

    [ https://issues.jboss.org/browse/CDI-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712196#comment-12712196 ] 

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
> -----------------------------------------------------------
>
>                 Key: CDI-184
>                 URL: https://issues.jboss.org/browse/CDI-184
>             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 {code}PersistenceProviderResolverHolder.getPersistenceProviderResolver()
> PersistenceProviderResolverHolder.setPersistenceProviderResolver(){code} 
> which holds the resolver to use. A modular environment is free to override the default resolver.
> h4. Bean Validation's approach
> Bean Validation uses a different approach to work around the nasty static field.
> {code}
> Validation
>   .byDefaultProvider()
>     .providerResolver( myOSGiResolver )
>   .configure() //we have ways to customize the ValidatorFactory further
>   .buildValidatorFactory();
> {code}
> Note that Bean VAlidation approach has another benefit, you can physically ask for a specific Bean Validation provider implementation
> {code}
> Validation
>   .byProvider( HibernateValidator.class )
>   .configure()
>     .ignoreXmlConfiguration() //bean validation configuration
>     .failSafe() //Hibernate specific configuration (type safe)
>   .buildValidatorFactory();
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira