[cdi-dev] [JBoss JIRA] (CDI-109) Invalid beans should not be injectable into extensions

Jozef Hartinger (Issue Comment Edited) (JIRA) jira-events at lists.jboss.org
Mon Nov 21 09:34:42 EST 2011


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

Jozef Hartinger edited comment on CDI-109 at 11/21/11 9:33 AM:
---------------------------------------------------------------

As discussed on the IRC channel, using events at bootstrap is the only way for extensions to cooperate in CDI 1.0. Although CDI 1.1 introduces alternative ways, existing extensions may rely on this.

In order to make the following paragraph shorter, I need to define this:
OMWIPDOE = an observer method with injection points defined on an extension :-)

The question remains if we should do something with OMWIPDOEs which may be invoked at bootstrap when the container is not possible to satisfy the injection points. One approach is to scan for OMWIPDOE upfront and issue a definition error. My opinion is that this is too restrictive since it disallows OMWIPDOEs to be used at runtime, which are currently allowed. IMHO, instead of adding further restrictions and validating upfront, the container should check this at event delivery. If an injection point of a OMWIPDOE cannot be satisfied and the container is in the bootstrap phase, it should recognize this as a definition error. As a result, we get the same guarantees (recognizing the problem at the deployment time) as with the upfront scanning while being less restrictive at the same time (OMWIPDOEs would work at runtime).
                
      was (Author: jharting):
    As discussed on the IRC channel, using events at bootstrap is the only way for extension to coordinate in CDI 1.0. Although CDI 1.1 introduces alternative ways, existing extensions may rely on this.

In order to make the following paragraph shorter, I need to define this:
OMWIPDOE = an observer method with injection points defined on an extension :-)

The question remains if we should do something with OMWIPDOEs which may be invoked at bootstrap when the container is not possible to satisfy the injection points. One approach is to scan for OMWIPDOE upfront and issue a definition error. My opinion is that this is too restrictive since it disallows OMWIPDOEs to be used at runtime, which are currently allowed. IMHO, instead of adding further restrictions and validating upfront, the container should check this at event delivery. If an injection point of a OMWIPDOE cannot be satisfied and the container is in the bootstrap phase, it should recognize this as a definition error. As a result, we get the same guarantees (recognizing the problem at the deployment time) as with the upfront scanning while being less restrictive at the same time (OMWIPDOEs would work at runtime).
                  
> Invalid beans should not be injectable into extensions
> ------------------------------------------------------
>
>                 Key: CDI-109
>                 URL: https://issues.jboss.org/browse/CDI-109
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Portable Extensions
>    Affects Versions: 1.0, 1.1.EDR1
>            Reporter: John Ament
>            Assignee: Pete Muir
>            Priority: Minor
>             Fix For: 1.1 (Proposed)
>
>
> Currently, you can inject beans that may not be ready yet into the extension's call back methods.  As an example, I can inject something application scoped like this in to an extension, but it should really be throwing a definition exception (or similar):
> public void handleABD(@Observes AfterBeanDiscovery abd, MyApplicationScopedBean masb) {
> }
> Pete had noted that really the only safe thing to inject, other than the observed call back, is the bean manager.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the cdi-dev mailing list