[cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

Martin Kouba (JIRA) issues at jboss.org
Wed Aug 24 07:45:01 EDT 2016

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

Martin Kouba commented on CDI-626:

Hm, I see. But if we do then a {{CDIProvider}} would have to return some "uninitialized" {{CDI}} instance anyway. So I don't see a difference here. Either CDIProvider impl or CDI impl would have to handle this. Actually, the returned CDI instance would have to handle this for all methods inherited from {{javax.enterprise.inject.Instance}}. From impl point of view, CDIProvider modification will be one method, CDI modification many methods.

> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.

This message was sent by Atlassian JIRA

More information about the cdi-dev mailing list