[cdi-dev] [Vote] @ApplicationScoped and visibility

[Jozef Hartinger]

On 11/26/2012 03:29 PM, Mark Struberg wrote:
> All current containers (EE and standalone, namely Weld, Glassfish, OpenWebBeans, JBossAS 6 and 7, WebSphere, TomEE) implement 1(b) as shown via the small example available at [1]
> Thus taking 1.a would introduce heavy backward compatibility issues.
It's not fair to say that all those containers implement 1(b). A bug in 
Weld (which also affects the application servers using it) causes Weld 
to unintentionally behave similarly to 1(b) in certain scenarios. This 
is far from fully implementing all the consequences of 1(b). Your 
testcase demonstrates one such scenario.

>
> Therefore I VOTE for 1.b
>
>
> As for question 2 I VOTE for 2.b as the 1-per-ear Scope already exists twice in the form of javax.ejb.Singleton and javax.inject.Singleton.
>
>
> LieGrue,
> strub
>
>
> [1] https://github.com/struberg/cdi_eartest
>
>
>
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: cdi-dev at lists.jboss.org
>> Cc:
>> Sent: Monday, November 26, 2012 2:44 PM
>> Subject: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>
>> CDI EG members,
>>
>> Please vote on the following two issues by indicating whether you prefer either
>> option (a) or (b) to both questions (1) and (2). Please vote asap, voting closes
>> as soon as I have a complete set of votes from the EG or at COB (Eastern) on
>> 30th Nov, whichever happens sooner :-)
>>
>> Question 1, Visibility
>> ---------------------------
>>
>> The CDI 1.0 specification states that only beans whose bean class is accessible
>> (using standard classloader visibility rules) can be injected into another bean.
>> For example, if you have a bean A in WAR, assuming standard Java EE classloader
>> structure, it wouldn't be available for injection in bean B, in an EJB
>> modiule. This generally makes sense, as the type is not visible either.
>>
>> CDI also offers two options to replace bean implementations transparently,
>> without explicitly selecting that implementation (either by type or using a
>> qualifier) - alternatives and specialization.
>>
>>
>> First, let's consider specialization. For example, if bean B, from the
>> example above, is specialized by bean S in the WAR, and bean C in the same EJB
>> module as B injects a type B, then what should be injected (if anything). The
>> CDI 1.0 specification addresses this issue by disabling any bean which has been
>> specialized across the entire application. Therefore, according to CDI 1.0, this
>> would result in an deployment problem (as there would be an unsatisfied
>> injection point).
>>
>> Alternatives are addressed a little differently in CDI 1.0. For example, if bean
>> B has an alternative A packaged in the WAR, then if A is selected in the war
>> only, then if bean C in the same EJB module as B injects a type B, it would be
>> injected with C. However, if A is selected for the EJB module as well, then the
>> deployment should fail as beans.xml of the EJB module references S which it
>> cannot see. Note that we have also added global visibility for alternatives in
>> CDI 1.1, which may need revising based on what is decided here.
>>
>> The EG has debated two options.
>>
>> (a) maintain the status quo, as described by the CDI 1.0 spec
>> (b) take an approach where visibility is isolated according to the calling
>> context. Thus, if a call originates via the WAR, then specialization and enabled
>> alternatives in the WAR are visible to any bean which is called in that stack.
>>
>> Approximately, Weld takes approach (a), and OWB takes approach (b), so which
>> approach is more backwards compatible here is debatable.
>>
>>
>> Question 2, @ApplicationScoped
>> ---------------------------------------------
>>
>> CDI implementations have not consistently shared @ApplicationScoped beans across
>> all modules of an EAR. Weld, and app servers built on Weld (those that we have
>> surveyed include JBoss AS, GlassFish, WebLogic) have shared application scoped
>> beans across the EAR. OWB isolates @ApplicationScoped beans to the calling
>> context of the WAR, however applications servers built on OWB have shared beans
>> across all modules of an EAR (this is certainly true of WebSphere, and I believe
>> it is true of TomEE).
>>
>> The EG has debated two options.
>>
>> (a) require @ApplicationScoped beans to be shared across all modules of an EAR
>> (b) take an approach where @ApplicationScoped beans are isolated to the calling
>> context
>>
>> Whichever approach is taken, the EG is agreed that a scope that addresses the
>> other option should be introduced.
>>
>> So, please indicated which options you favour:
>>
>> Question 1: (a) OR (b)
>> Question 2: (a) OR (b)
>>
>> Thanks,
>>
>> Pete
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev