[
https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy...
]
Jens Schumann commented on CDI-274:
-----------------------------------
I have been running into a similar issue just recently and thought it would be good to
share the problem with you guys.
As discussed on the owb user mailing list [1] we use an AfterBeanDiscovery extension that
added a bean of a certain type if no bean of this type exists already. We use this
extension to add a UserTransaction to the runtime if the runtime does not provide one
(inside vs. outside Java EE runtime). My extension used BeanManager#getBeans() for this
check.
Because of some owb internal issues I switched from using getBeans to observing
ProcessBean to detect the UserTransaction. This works perfectly for my current setup and
could be the way to do it with CDI 1.1 where CDI-315 applies.
Nevertheless my solution will only work for "discovered" beans. Am I right that
Java EE Resources (such as my UserTransction) are "discovered"? According to
ProcessBean javadoc Java EE Resources are treated as producer fields. Right?
Also: Since getBeans shall throw an Exception now would it be worth to add a comment to
the spec that an extension can achieve similar results by observing ProcessBean? I got the
(now obvious) hint from Arne Limburg...
[1]
http://mail-archives.apache.org/mod_mbox/openwebbeans-user/201303.mbox/%3...
BeanManager#getBeans() shall throw an Exception if called before
AfterDeploymentValidation
------------------------------------------------------------------------------------------
Key: CDI-274
URL:
https://issues.jboss.org/browse/CDI-274
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Pete Muir
Fix For: 1.1.PFD
We recently had the erroneous case in DeltaSpike that an Extension did call
BeanManager#getBeans() in an @Observes ProcessBean method.
Doing so leads to random behaviour as the result of getBeans() depends on the order in
which the other beans got processed already. E.g. getBeans(Object.class) will return an
empty list for the first bean getting processed, and will return all beans -1 for the last
bean. That just makes no sense and will create unreproducible bugs.
PROPOSAL:
We shall add spec language to BeanManager#getBeans() that any invocation before the
AfterDeploymentValidation phase will result in a deployment error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira