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

[Mark Struberg]

weld behaves that way since ever. and in all the 2 years since CDI is final there is no version available where it worked like described in 1a. facts have nothing to do with fair or not...

------------------------------
Jozef Hartinger schrieb am Mo., 26. Nov 2012 09:21 PST:

>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
>