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

[Joseph Bergmark]

As written, I would vote:

1) a
2) a

I believe the OWB actually follows 1a as the question is currently 
written.  When the EJB is executing, the thread context classloader would 
be that of the ejb module so the correct bean would be injected for that 
module.  I think what tends to confuse this issue, at least for me, is 
when bean B is in a jar in the lib directory of the ear and not in an 
ejb-jar.  As OWB keys off the TCCL, so it is going to act as if that bean 
was part of whatever context its currently executing inside.  In my mind 
this boils down to TCCL vs. awareness of what jar a class was defined in 
order to determine alternatives and specialization.

Sincerely,

Joe Bergmark




From:
Pete Muir <pmuir at redhat.com>
To:
cdi-dev at lists.jboss.org, 
Date:
11/26/2012 08:44 AM
Subject:
[cdi-dev] [Vote] @ApplicationScoped and visibility
Sent by:
cdi-dev-bounces at lists.jboss.org



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20121126/8a74352e/attachment-0001.html