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

[Mark Struberg]

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


Nope, OWB follows 1b and is thus perfectly in sync with all the other EE containers I tested (feel free to grab my app and test yourself!). CDI != EJB. There is (currently) no magical TCCL change involved in any CDI call chain. Not in OWB and also not in Weld so far afaik. 


Regarding Question 2: Please note that some IBM colleague of you explicitly added a ThreadLocal for the ApplicationContext to make it distinguishable even in cases where there is no classloader isolation in place between webapps. I'm not sure what configuration is in place right now in WebSphere. Since OWB is highly pluggable that might be different to core OWB. But please don't mix up WebSphere behaviour and OWB core behaviour!



LieGrue,
strub



>________________________________
> From: Joseph Bergmark <bergmark at us.ibm.com>
>To: cdi-dev at lists.jboss.org 
>Sent: Monday, November 26, 2012 6:54 PM
>Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
> 
>
>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
>
> 
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>