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

Romain Manni-Bucau (JIRA) issues at jboss.org
Wed Aug 24 08:35:00 EDT 2016


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

Romain Manni-Bucau commented on CDI-626:
----------------------------------------

Ok so rephrased it means: when should the resolution of the CDI context occurs: in the provider or in the CDI instance. For me the provider is a hook to let the impl be plugged so I'm tempted to say we can let getCdi() be passthrough and fail on getBeanManager() only. What you can "uninitialized" could actually be "initialized" as JNDI context is active but a resource can not be bound behind a name.

> 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
(v6.4.11#64026)


More information about the cdi-dev mailing list