[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... ] Mark Struberg edited comment on CDI-129 at 10/20/12 7:04 AM: ------------------------------------------------------------- Yesterday Gerhard, David and I had a really good late night discussion. I think I now understand a bit better where you guys are coming from conceptually. The isolation rules Jozef proposed are the ones from EJB. But CDI beans are not EJBs! CDI introduced the notion of Contexts and proxying. With EJBs you don't have cross-scope injection abilities, etc. A lot concepts are fundamentally more open and different in CDI. Thus I fear we also cannot apply EJB rules 1:1 to CDI beans. Now think about it again: you basically like to define @ApplicationScoped as alias for (EJB) @Singleton, right? That's what it boils down to if I read your proposal. Now the question is: why the hack do we need that? Just use an @Singleton EJB if you like to share state between different WAR files, MDB and stuff! So we do not even need to introduce any new scope because a thinkg like "@EnterpriseApplicationScoped" already exists: @Singleton. Maybe that was the reason why Gavin explicitly specified @ApplicationScoped web-app/servlet centric as 1-per-WAR by writing "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7, “Context management for built-in scopes” represent the standard scopes defined by the Java Servlets specification." The argument with the TCK is also not the strongest one. The JCP defines the following rule when resolving ambiguous definitions: 1.) JavaDoc 2.) Spec Wording 3.) TCK We (OWB) already reported 30++ bugs in the TCK and I guess others did the same. If you consider how many tests there are then this is only a small part, but still. Btw, it *really* rocks that the TCK is open sourced! This allows us to easily fix shortcomings, add more use cases and most importantly: talk about scenarios! With closed TCKs we would not even be allowed to talk about TCK use cases in a public bug tracker! @Jozef your argumentation with semi-static wiring is not quite right. This is perfectly allowed and even necessary in CDI 1.0. Please look at Bean<T> and InjectionPoint. Then look at Bean#getInjectionPoints(). This doesn't return a list of Bean<?> to be injected but only a list of InjectionPoints. And those just contain the Type and not the resolved Bean<?>. So upon creating the Contextual Instance via T Bean<T>#create(); a CDI container has to first do getInjectionPoints() and then for each InjectionPoint RESOLVE the correct Bean<?>. This is *not* defined in a static way in CDI 1.0 but fully dynamic! was (Author: struberg): Yesterday Gerhard, David and I had a really good late night discussion. I think I now understand a bit better where you guys are coming from conceptually. The isolation rules Jozef proposed are the ones from EJB. But CDI beans are not EJBs! CDI introduced the notion of Contexts and proxying. With EJBs you don't have cross-scope injection abilities, etc. A lot concepts are fundamentally more open and different. Thus I fear we also cannot apply EJB rules 1:1 to CDI beans. Now think about it again: you basically like to define @ApplicationScoped as alias for (EJB) @Singleton, right? That's what it boils down to if I read your proposal. Now the question is: why the hack do we need that? Just use an @Singleton EJB if you like to share state between different WAR files, MDB and stuff! So we do not even need to introduce any new scope because a thinkg like "@EnterpriseApplicationScoped" already exists: @Singleton. Maybe that was the reason why Gavin specified @ApplicationScoped as 1-per-WAR by writing "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7, “Context man- agement for built-in scopes” represent the standard scopes defined by the Java Servlets specification." The argument with the TCK is also not the strongest one. The JCP defines the following rule when resolving ambiguous definitions: 1.) JavaDoc 2.) Spec Wording 3.) TCK We (OWB) already reported 30++ bugs in the TCK and I guess others did the same. If you consider how many tests there are then this is only a small part, but still. Btw, it *really* rocks that the TCK is open sourced! This allows us to easily fix shortcomings, add more use cases and most importantly: talk about scenarios! With closed TCKs we would not even be allowed to talk about TCK use cases in a public bug tracker! @Jozef your argumentation with semi-static wiring is not quite right. This is perfectly allowed and even necessary in CDI 1.0. Please look at Bean<T> and InjectionPoint. Then look at Bean#getInjectionPoints(). This doesn't return a list of Bean<?> to be injected but only a list of InjectionPoints. And those just contain the Type and not the resolved Bean<?>. So upon creating the Contextual Instance via T Bean<T>#create(); a CDI container has to first do getInjectionPoints() and then for each InjectionPoint RESOLVE the correct Bean<?>. This is *not* defined in a static way in CDI 1.0 but fully dynamic! -- 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