[cdi-dev] [JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation

[Jens Schumann (JIRA)]

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

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/%3c90EFADCA8D66DA4DA4CEC2F2BFE26F2B2DB91737@K99F-PEXC01.openknowledge.de%3e
                
> 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