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

[Stuart Douglas (JIRA)]

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

Stuart Douglas commented on CDI-129:
------------------------------------

I still have not fully thought this through, but some more thoughts I have had on the subject:

When you say "one which makes users get different contextual instances depending on where the injection into gets made is an absolute no-go", I read your 3rd option as doing basically the same thing (the same injection point can resolve to different beans, but depending on the current thread state, which to my mind sounds even worse in a lot of ways).

Also your statement "this is NOT needed if we do not inject into a bean which is of a broader scope than 1 per webapp" is not correct. Say you have a request scoped bean (X) in the top level module that inject a User, and then you have a war that @Specialises the User bean. Depending on the web app that is active X.user will resolve differently. You wil not be affected by the proxy bug in the current implementation, however that is an implementation issue, and you still have to do semi-static wiring (although at injection time rather than invocation time). Also we still have to deal with custom scopes, which could cover the whole ear, so even then this does not help. 

I also really dislike the way that wars are treated as 'special' in your proposal, not every EE app has a war. 

Anyway, back to the actual scope issue and ignoring the specialisation issue for now, I think that we have two options:

1) Make ApplicationScoped per war/module, and add @EnterpriseApplicationScoped
2) Make ApplicationScoped per ear, and add @ModuleScoped

I prefer option 2:
- @EnterpriseApplicationScoped does not make much sense outside an ear. If you are writing portable code using @EnterpriseApplicationScoped for a '1 per app' scope seems a bit misleading when it may not even be an enterprise app.
- ModuleScoped also also more consistent with regard to things like EJB timers and invocations, I have never really heard an EJB jar referred to as an 'application', so IMHO ModuleScoped makes more sense here. I also really don't think we should be treating wars any different to other modules.

Now, on to the portable extension issue. Weld creates a single instance of a portable extension, I must admit I was quite surprised when I found out OWB does it differently. I know that a lot of portable extensions that I have written just assume that there is a single instance, and will basically do things like add the same bean twice when they are instantiated twice. I am not really sure how to resolve this, one option that comes to mind is allowing @ModuleScoped, @ApplicationScoped or @EnterpriseApplicationScoped on the PE class itself (depending on the annotation name we go with), although to be honest I don't know if I really like that idea that much.

This needs a lot more thought.










                
> 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