[ https://issues.jboss.org/browse/CDI-109?page=com.atlassian.jira.plugin.sy... ] Richard Hightower commented on CDI-109: --------------------------------------- Can we expand on this? I am not sure I understand. Is there some supporting document blog, email thread? This is not clear. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-109?page=com.atlassian.jira.plugin.sy... ] Mark Struberg edited comment on CDI-109 at 4/30/11 4:05 PM: ------------------------------------------------------------ 11.5. "Container lifecycle events" defines that system events work like normal @Observes methods. For a normal @Observes method, you can have additional parameters which get injected by the container: void clearCaches(@Observes CredentialsChangedEvent cce, BeanManager bm, User usr) {...} In this example, the bm and usr instances will get injected by the container. See 10.4.2. "Declaring an observer method": "In addition to the event parameter, observer methods may declare additional parameters, which may declare qualifiers. These additional parameters are injection points." But for Extensions, the only beans which can get injected are actually the builtin ones which already got initialized (e.g. the BeanManager itself). All other custom class beans are just not yet available for injection at the time the container gets bootstrapped. was (Author: struberg): 11.5. "Container lifecycle events defines" that system events work like normal @Observes methods. For a normal @Observes method, you can have additional parameters which get injected by the container: void clearCaches(@Observes CredentialsChangedEvent cce, BeanManager bm, User usr) {...} In this example, the bm and usr instances will get injected by the container. See 10.4.2. "Declaring an observer method": "In addition to the event parameter, observer methods may declare additional parameters, which may declare qualifiers. These additional parameters are injection points." But for Extensions, the only beans which can get injected are actually the builtin ones which already initialized. All other custom class beans are just not yet available for injection at the time the container gets bootstrapped. In fact, I wonder if it even makes sense to inject the BeanManager... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-109?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-109: ------------------------------- We can go two ways here. Either make it nonportable to look up beans in extensions, or mandate it's not possible. Advantage of nonportable is that it allows containers to innovate here. Any thoughts? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-109?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-109: -------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jboss/cdi/pull/32 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-109?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger reopened CDI-109: --------------------------------- This requires further clarification. The spec currently says that: {quote} Service providers may have observer methods, which may observe any event, including any container lifecycle event, and obtain an injected BeanManager reference. If other beans are injected into service providers, non-portable behavior results. {quote} The first part clearly indicates, that it is the *observer method* who may obtain the BeanManager. However, the second part {quote} If other beans are injected *into service providers* {quote} suggests the service providers can receive other types of injection (e.g. field injection), which is not allowed by the specification. The other issue is with the normal observer methods (those not observing a container lifecycle event). Such observer methods can be defined on extension and we should guarantee that if invoked at runtime, they behave the same as observer methods defined on other beans (i.e. injecting any bean is allowed). Hopefully, this table illustrates the problem better: |This table describes injection guarantee the container should provide for a given type of observer method defined on an Extension in a particular phase|*container lifecycle event observer method*|*normal observer method*| |*container initialization*|BeanManager, injection of other beans non-portable|BeanManager, injection of other beans non-portable| |*runtime*|N/A|any bean can be injected| -- 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

[ https://issues.jboss.org/browse/CDI-109?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-109: ------------------------------- I would prefer to disallow normal observers at bootstrap for now -- 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

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

[ https://issues.jboss.org/browse/CDI-109?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-109: ------------------------------- Issued a pull at https://github.com/jboss/cdi/pull/89 for this and CDI-245, which resolves the issue around "inject into service providers" which is was a mistake. I haven't allowed extensions to inject other beans at runtime, that seems overly complex. If an extension wants to do something at runtime, it should define a bean that does it. The bean can inject the extension to obtain any information it needs from container initialization. I've also left what happens when the container injects something other than the BeanManager into an observer method as undefined, as I think there is room for an implementation to innovate here. It also allows an implementation to allow this runtime, for example. -- 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

[ https://issues.jboss.org/browse/CDI-109?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-109. --------------------------- Resolution: Done -- 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