Pete Muir commented on CDI-129:
Due to the well defined TCCL behaviour in the EE umbrella spec it is perfectly viable that
A might see B IF it is invoked in a request of the webapp containing A. So technically
from the EE spec there is NO such restriction you mentioned. It's just easier for a
container vendor to implement.
I don't believe the TCCL is relevant here, it's only ever used explicitly to load
classes, not implicitly if you instantiate via the new keyword, which is the model we are
trying to follow.
Another point: who likes to go to all the other spec leads like JPA and most important JSF
and confess that we messed up? Especially who gonna tell Ed that he cannot drop JSF
ManageBeans because we have no replacement for his JSF @ApplicationScoped which exists
since 10 years and he finally agreed to get rid of?
I'm quite happy to take on any tasks that involve discussions with other spec leads.
As JSF is prepared to deprecate scopes, and move people over to standard CDI scopes, there
is a code change required anyway. Therefore, if we were to introduce a @ModuleScoped or
similar, I think JSF apps could move from JSF application scope to this.
Clarify behaviour of @ApplicationScoped in EARs
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.0
Reporter: Mark Struberg
Assignee: Pete Muir
Fix For: 1.1 (Proposed)
Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet
specification' this means that you will get a new instance for every WebApplication
There is currently no specified CDI scope for providing a single shared instance for a
We could (ab-)use @Singleton for that, but this is currently not well defined at all.
Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes.
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