[ https://issues.jboss.org/browse/CDI-164?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-164: -------------------------- Assignee: Pete Muir Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) Please review https://github.com/jboss/cdi/pull/104 -- 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

[ https://issues.jboss.org/browse/CDI-164?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger reopened CDI-164: --------------------------------- Multiple reasons for reopening: h3. Bean Manager The spec says: Any decorators associated with BeanManager will not be applied. It is not clear whether this means that decorators are not applied to BeanManager objects injected into Extensions during bootstrap only or whether it means that injected BeanManager objects are never ever decorated. h3. The extension problem For each extension there is a bean that allows the extension to be injected into other beans. Should the injected extension support decoration? We can only support this at runtime (no decorators would be applied to extension instances at bootstrap). If we decide to support decoration of injected extension we should think about whether extension instances obtained via BeanManager.getExtension() should support decoration or not. h3. Consistency The spec says: "Decorators may be associated with any managed bean that is not itself an interceptor or decorator, with any EJB session bean or with any *built-in* bean." The spec currently defines a set of container-provided beans out of which a subset is referred to as "built-in" beans. For example, the injected InjectionPoint is not explicitly labeled as "built-in bean". The same applies for injected Bean, Interceptor, Decorator (5.5.8), Validator, ValidatorFactory, ConstraintValidator and extension beans. We should either say that decorators may be associated with any container-provided bean or we should explicitly label all the container-provided beans as "built-in". h3. Passivation Most of the built-in beans are passivation capable dependencies. We should required decorators of built-in beans to be passivation capable. Otherwise the container cannot store a decorator's state when it passivates e.g. an Event instance. -- 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

[ https://issues.jboss.org/browse/CDI-164?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-164: -------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) -- 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

[ https://issues.jboss.org/browse/CDI-164?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-164: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) -- 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

[ https://issues.jboss.org/browse/CDI-164?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-164: ------------------------------------- I though the intention was to enable decoration of all container-provided beans and specifying the requirement for those labeled with "built-in" was only an oversight. However, it seems it was actually intentional. Here's a summary of what is currently required to support decoration if we go strictly with the "built-in label": * Event * Instance * Conversation * HttpServletRequest / HttpSession / ServletContext * InjectionPoint * Principal * UserTransaction The container-provided beans that are not required to support decoration: * extensions (injected instances) * Bean, Interceptor, Decorator (@Default, @Intercepted or @Decorated) * Validator * ValidatorFactory Built-in beans not supporting decoration: * BeanManager -- 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

[ https://issues.jboss.org/browse/CDI-164?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-164: ------------------------------- Of these, the only ones that could be useful to decorate would be the validator stuff, and they should probably be called "built-in beans" anyway... -- 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

[ https://issues.jboss.org/browse/CDI-164?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-164: ---------------------------------- So the TCK will only test: * Event * Instance * Conversation * HttpServletRequest / HttpSession / ServletContext * InjectionPoint * Principal * UserTransaction Everyone ok with this? -- 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

[ https://issues.jboss.org/browse/CDI-164?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-164. --------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) Resolution: Done Clarification made as part of CDI-272 -- 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