[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 07:33:00 EDT 2016
[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283362#comment-13283362 ]
Romain Manni-Bucau commented on CDI-626:
----------------------------------------
I agree getBeanManager() should throw an exception but also means CDIProvider.getCDI() doesn't otherwise we can't call it. Moreover CDIProvider is a plain SPI today and I think it is good to keep it simple so I would put the behavior in the impl and therefore CDI only. Nice thing doing that is the API stay simple and deployment doesn't affect runtime behavior (OSGi/JBoss module or graph classloading, hierarchical classloading, flat classloading).
> 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