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

[Romain Manni-Bucau (JIRA)]

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

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

well a bit more than taste cause it implies how an application can test if CDI is there: is getCdi() enough or should it tries to call one CDI method too? Also not sure what "container" means in your comment, I see CDI as the CDI container handle so anything before is not really CDI (= the CDIProvider is a bridge to CDI but doesn't require CDI). That said agree we just need to make it clear. One point can maybe be to check the api jars out there and see if changing the impl isn't easier since people will maybe not upgrade their API :s.

Also it viciously brings the question of the contextuality of CDIProvider which is maybe not something we want to "spec" yet (ie is the provider bound to an impl and one context once the lookup is done or is CDI only contextual?).

> 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)