[ https://issues.jboss.org/browse/CDI-245?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-245: -------------------------- We have to be very careful about how we define this. The only observer can be another extension. We'll need to define what happens if a non-extension has an observer for said event on it. -- 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-245?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-245: ------------------------------- I would prefer to explicitly allow extensions to use BeanManager.getExtension(). WDYT? -- 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-245?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-245: ------------------------------- Today, the only thing you can inject in a portable fashion is the BeanManager. Implementations normally support injecting other things, and we could certainly open up a limited list (like extensions). -- 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-245?page=com.atlassian.jira.plugin.sy... ] Mark Struberg edited comment on CDI-245 at 8/16/12 8:49 AM: ------------------------------------------------------------ In CDI-1.0 it's just undefined what you can inject at bootup. We can only exclude what explicitely is forbidden or defined to get started afterwards. But there is currently no wording that specifies that e.g. @Stateless beans cannot be @Injected. For Extensions I looked at 11.5: {quote} The container instantiates a single instance of each extension at the beginning of the application initialization process and maintains a reference to it until the application shuts down. The container delivers event notifications to this instance by calling its observer methods. For each service provider, the container must provide a bean of scope @ApplicationScoped and qualifier @Default, sup- porting injection of a reference to the service provider instance. The bean types of this bean include the class of the service provider and all superclasses and interfaces. {quote} Thus a.) all Extensions get loaded before the first container lifecycle event gets fired b.) all Extensions are beans which are available for injection c.) all Extensions are @ApplicationScoped. I guess the problem is that the ApplicationContext only gets started after AfterDeploymentValidation, right? In DeltaSpike we currently use the Extension injection for runtime communication between an Interceptor and it's Extension and not at boot time. was (Author: struberg): In CDI-1.0 it's just undefined what you can inject at bootup. We can only exclude what explicitely is forbidden or defined to get started afterwards. But there is currently no wording that specifies that e.g. @Stateless beans could be @Injected. For Extensions I looked at 11.5: {quote} The container instantiates a single instance of each extension at the beginning of the application initialization process and maintains a reference to it until the application shuts down. The container delivers event notifications to this instance by calling its observer methods. For each service provider, the container must provide a bean of scope @ApplicationScoped and qualifier @Default, sup- porting injection of a reference to the service provider instance. The bean types of this bean include the class of the service provider and all superclasses and interfaces. {quote} Thus a.) all Extensions get loaded before the first container lifecycle event gets fired b.) all Extensions are beans which are available for injection c.) all Extensions are @ApplicationScoped. I guess the problem is that the ApplicationContext only gets started after AfterDeploymentValidation, right? In DeltaSpike we currently use the Extension injection for runtime communication between an Interceptor and it's Extension and not at boot time. -- 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-245?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-245: ------------------------------- I don't think there is a problem with allowing extensions to be injected in CDI 1.1, the ApplicationContext is always active, so that shouldn't be a limitation. -- 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-245?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-245: ------------------------------- Sorry, I hadn't realised that ;-) {quote} Service providers may have observer methods, which may observe any event, including any container lifecycle event, and obtain an injected BeanManager reference. {quote} So, although it's not explicit, it's implied that all you can inject is a BeanManager, IMO. Also, yes, good point about contexts -- 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-245?page=com.atlassian.jira.plugin.sy... ] Pete Muir edited comment on CDI-245 at 8/24/12 6:13 PM: -------------------------------------------------------- Interestingly, the quote does say "may observe any event", which supports [~mkouba]'s original point. I think we can close this issue out by saying: * If a portable extension fires a container lifecycle event, non-portable behavior results * That an extension can fire a regular event by calling BeanManager.fireEvent() * Opening a new issue around contexts being active during bootstrap, as we don't really need that, as extensions are not defined as beans, but as objects which can take advantage of some CDI capabilities I'll draft up these changes and open a new issue. was (Author: pmuir): Interestingly, the quote does say "may observe any event", which supports [~mkouba] original point. I think we can close this issue out by saying: * If a portable extension fires a container lifecycle event, non-portable behavior results * That an extension can fire a regular event by calling BeanManager.fireEvent() * Opening a new issue around contexts being active during bootstrap, as we don't really need that, as extensions are not defined as beans, but as objects which can take advantage of some CDI capabilities I'll draft up these changes and open a new issue. -- 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-245?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-245: -------------------------- Assignee: Pete Muir Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) -- 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-245?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-245: ------------------------------- I pondered for a while over that same paragraph, when I came to my conclusion that extensions aren't defined as beans. Typically, when the spec wants something to be a bean, it says "is a ... bean" e.g. 3.1.1 (Managed beans) {quote} A top-level Java class is a managed bean if it is defined to be a managed bean {quote} or 3.2 (Session beans) {quote} A session bean is a bean that is implemented by a session bean with an EJB 3.x client view. {quote} On the other hand, when the spec wants the container to provide a bean which provides access to an externally managed resource it says "must provide a bean" e.g. 3.7 (Additional built-in beans) {quote} A Java EE or embeddable EJB container must provide the following built-in beans, all of which have qualifier @Default: a bean with bean type javax.transaction.UserTransaction, allowing injection of a reference to the JTA UserTransaction, (etc) {quote} To me, it's fairly clear that the spec isn't saying "UserTransaction is bean", but is saying "There must be a bean that represents the UserTransactions". Here, the spec clearly uses the second form, so my reading is that "the container must provide a bean that represents the extension". I think this reading is backed by the spec saying "An extension is a service provider..." and "For each service provider,...", and then going on to refer to the "extension", and not the "extension bean". Firstly, because it clearly says "an extension *is a* service provider" and not "an extension is a bean implemented by a service provider" (or better written words to that effect). Secondly, because the spec is quite clear about when something is a bean or not elsewhere, and here it makes no effort to say "an extension is a service provider". WDYT? Do you see why I came to this conclusion? Regarding field injection into a service provider, I don't believe that has ever been allowed specifically by the specification (it always talked about injection into the observer method only), and I think that this makes sense. The "If other beans are injected into a service provider" was something I added to EDR1, that I think was a mistake now. I also choose not to address defining anything other than the container firing lifecycle events as non-portable, as I don't believe I have a good answer to that question right now. I would actually much prefer we restrict it by defining something on observer methods such as "an extension observer method need only to respond to container lifecycle events fired by the container and need not respond to events fired by an application" or something like that. WDYT? -- 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-245?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-245: ------------------------------- Right, to *inject* an extension into something else, it doesn't matter which view we take. BTW yes, I'm happy to remove BeanManager.getExtensions() in favor of injecting extensions into extensions. It's when we consider what facilities of CDI that an extension can take, that this point matters. If we take the view you espouse, then we need to explicitly forbid everything that it can't do. If we take the view I outline, then we simply need to list the things it can do. -- 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