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

[Jozef Hartinger (JIRA)]

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

Jozef Hartinger edited comment on CDI-129 at 10/22/12 5:32 AM:
---------------------------------------------------------------

{quote}@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!{quote}

No! The reason for that is because Beans are decoupled. Otherwise an extension would need to provide the entire Bean graph should it want to add a new Bean.

What the spec says is that for a given InjectionPoint declared on a Class that is packaged in a given module, there is *always* a single Bean<?> that this InjectionPoint resolves to. Otherwise, it is a deployment error. This is what I refer to as "static wiring" and this is what CDI specifies (sections 5.1 and 5.2).

If the same InjectionPoint can resolve to different beans depending on the current thread state, this is what I refer to as "semi-static approach" (you came up with the term)


                
      was (Author: jharting):
    {quote}@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!{quote}

No! The reason for that is because Beans are decoupled. Otherwise an extension would need to provide the entire Bean graph should it want to add a new Bean.

What the spec says is that for a given InjectionPoint declared on a Class that is packaged in a given module, there is *always* a single Bean<?> that this InjectionPoint resolves to. Otherwise, it is a deployment error. This is what I refer to when as "static wiring" and this is what CDI specifies (sections 5.1 and 5.2).

If the same InjectionPoint can resolve to different beans depending on the current thread state, this is what I refer to as "semi-static approach" (you came up with the term)


                  
> 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