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

[Mathieu ANCELIN (Commented) (JIRA)]

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

Mathieu ANCELIN commented on CDI-184:
-------------------------------------

I completely agree with this one. I've already expressed my concerns about using CDI.current() in a modular environment.

I really like the Bean Validation approach to solve this issue, it's very clean.

It may also be nice to provide the module metadata for CDI 1.1 jar file (OSGi, etc ...).
                
> 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