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

[Mark Struberg (JIRA)]

    [ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727121#comment-12727121 ] 

Mark Struberg commented on CDI-129:
-----------------------------------

>  Firstly, here is how the modularity work in CDI:
Let's say this is your view and is one of n possible interpretations of the spec wording.

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.

And your example is also _perfectly_ broken from a user experience pov!
If you inject X in a shared jar you would get another contextual instance than injecting X in a JSF backing bean that way! Hell, this is SICK SICK SICK! No user would be able to use that stuff!

I have a @Inject User usr; in my MailFormular backing bean and the same code in my MailService and would get 2 DIFFERENT users? You're kidding me, right?

The are only 2 practical ways to do this properly for users: 
1.) restrict any @Specializes or @Alternative of an interface to the visibility area it got defined in. In other words if you have a User interface in a shared jar in your EAR we disallow @Specializes or @Alterative in any WAR. But again, this is NOT defined in CDI-1.0 yet!

2.) use a proper proxy which only proxies the injection point type (in our case X) and not only resolve the contextual instance but also the proper Bean<X> dynamically on each invocation IF it got injected into a 'broader scoped bean'. And here we come back to my first argument: by keeping the specified behaviour of CDI-1.0 as 1 per webapp we would not have any 'broader' scope in CDI and thus we dont need to deal! We could introduce all the necessary handling in CDI-1.1 together with the broader @EnterpriseApplicationScoped.

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?

                
> Clarify behaviour of @ApplicationScoped in EARs
> -----------------------------------------------
>
>                 Key: CDI-129
>                 URL: https://issues.jboss.org/browse/CDI-129
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    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 (WAR file).
> There is currently no specified CDI scope for providing a single shared instance for a whole EAR.
> 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