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

[Mark Struberg]

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.

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
>