[cdi-dev] [JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Stuart Douglas edited comment on CDI-129 at 10/18/12 6:49 AM: -------------------------------------------------------------- There is a lot of stuff here, but firstly: a) Bean is quite well defined in CDI. If it gets a ProcessBean event thrown then it is a bean. b) You are correct and TTCL is irrelevant here. Class loading is actually pretty irrelevant here, the EE platform spec defines class loading in terms of classes that must and must not be visible, and allows vendors to implement that with whatever class loading arrangement works So from what I see the problem is that there is a conflict in the spec to do with how injection point resolution works with scoping. 5.2.1 makes it pretty clean that every injection point must resolve to one and only 1 bean. In Mark's example, it actually resolves to different beans, due to scoping issues, and this is a problem that we need to sort out in the spec. Making ApplicationScoped be a per web application thing however is not a solution to this problem. This would mean that different beans resolve to the same injection point depending on the current context, which completely destroys static wiring, and we get back to a Seam 2 style resolution at injection time. It also makes the CDI deployment dependent on the current web app. What happens when there is no web app in an ear? What happens with a standalone jar? what happens with a SE app? Mark, from what I am reading it sounds like you are trying to bring back the worst of Seam 2 (I know you probably did not use Seam 2, but the approach was pretty much exactly what you are describing, and it had a lot of problems). IMHO we should just add @WebApplicationScoped and tighten up the spec to remove the scope problems, so if a bean ends up resolving injection points differently depending on the current archive it is a deployment error. was (Author: swd847): There is a lot of stuff here, but firstly: a) Bean is quite well defined in CDI. If it get's a ProcessBean event thrown then it is a bean. b) You are correct and TTCL is irrelevant here. Class loading is actually pretty irrelevant here, the EE platform spec defines class loading in terms of classes that must and must not be visible, and allows vendors to implement that with whatever class loading arrangement works So from what I see the problem is that there is a conflict in the spec to do with how injection point resolution works with scoping. 5.2.1 makes it pretty clean that every injection point must resolve to one and only 1 bean. In Mark's example, it actually resolves to different beans, due to scoping issues, and this is a problem that we need to sort out in the spec. Making ApplicationScoped be a per web application thing however is not a solution to this problem. This would mean that different beans resolve to the same injection point depending on the current context, which completely destroys static wiring, and we get back to a Seam 2 style resolution at injection time. It also makes the CDI deployment dependent on the current web app. What happens when there is no web app in an ear? What happens with a standalone jar? what happens with a SE app? Mark, from what I am reading it sounds like you are trying to bring back the worst of Seam 2 (I know you probably did not use Seam 2, but the approach was pretty much exactly what you are describing, and it had a lot of problems). IMHO we should just add @WebApplicationScoped and tighten up the spec to remove the scope problems, so if a bean ends up resolving injection points differently depending on the current archive it is 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