[
https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy...
]
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)