7:44 a.m.
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
8:08 a.m.
I'm recording the results in a Google Spreadsheet, read-only version published at
https://docs.google.com/spreadsheet/pub?key=0ApqHbXzB1R1gdDFTbnJpR2hxdjBF...
On 26 Nov 2012, at 13:44, Pete Muir wrote:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
8:08 a.m.
Red Hat vote (a) for question 1, and (a) for question 2.
On 26 Nov 2012, at 13:44, Pete Muir wrote:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
8:29 a.m.
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(a)redhat.com>
To: cdi-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
11:21 a.m.
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(a)redhat.com>
> To: cdi-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
11:54 a.m.
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(a)redhat.com>
To:
cdi-dev(a)lists.jboss.org,
Date:
11/26/2012 08:44 AM
Subject:
[cdi-dev] [Vote] @ApplicationScoped and visibility
Sent by:
cdi-dev-bounces(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
1:41 p.m.
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(a)us.ibm.com>
To: cdi-dev(a)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(a)redhat.com>
To: cdi-dev@lists.jboss.org,
Date: 11/26/2012 08:44 AM
Subject: [cdi-dev] [Vote] @ApplicationScoped
and visibility
Sent by: cdi-dev-bounces@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
2:47 p.m.
On 26 Nov 2012, at 19:41, Mark Struberg wrote:
> 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.
Right. Weld never sets the TCCL. But other things such as EJB might to in JBoss AS.
Stuart, can you comment?
3:12 p.m.
As Joe already mentioned, maybe we should split this into EJBs with CDI annotations on
them and 'pure CDI beans'?
In the case of pure CDI beans like @Dependent or JSR-330 beans - basically all beans
without a proxy - I have no clue where one would do the TCCL switch.
I read what Jozef said to mean "It's not correct ...".
And he is
correct, as he says Weld does behave like (b) in edge cases, however it
certainly doesn't behave like (b) in mainstream cases.
Show off, Pete ;)
I already published a few examples for @Specializes, @Alternatives and could easily add
@Decorator and @Interceptor examples. All show 1.(b) behaviour on Weld, GlassFish,
JBossAS, etc. I'm still missing a single example where it's a clear 1.(a) in an
EAR scenario..
To again emphasise this: there is no single container which is _not_ broken for EAR right
now the one way or the other. We could of course keep this backward compatible ;)
LieGrue,
strub
----- Original Message -----
From: Pete Muir <pmuir(a)redhat.com>
To: Mark Struberg <struberg(a)yahoo.de>
Cc: Joseph Bergmark <bergmark(a)us.ibm.com>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)lists.jboss.org>
Sent: Monday, November 26, 2012 9:47 PM
Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>> 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.
Right. Weld never sets the TCCL. But other things such as EJB might to in JBoss
AS. Stuart, can you comment?
3:28 p.m.
On 26 Nov 2012, at 21:12, Mark Struberg wrote:
As Joe already mentioned, maybe we should split this into EJBs with
CDI annotations on them and 'pure CDI beans'?
In the case of pure CDI beans like @Dependent or JSR-330 beans - basically all beans
without a proxy - I have no clue where one would do the TCCL switch.
Agreed.
> I read what Jozef said to mean "It's not correct ...". And he is
> correct, as he says Weld does behave like (b) in edge cases, however it
> certainly doesn't behave like (b) in mainstream cases.
Show off, Pete ;)
I'm not sure what you mean here. I was simply saying that I hadn't had the same
inference you had from Jozef's comment.
I already published a few examples for @Specializes, @Alternatives
and could easily add @Decorator and @Interceptor examples. All show 1.(b) behaviour on
Weld, GlassFish, JBossAS, etc. I'm still missing a single example where it's a
clear 1.(a) in an EAR scenario..
Sure, the more examples we have the better!
I'll check with Jozef exactly where Weld does and doesn't follow the 1(a) behavior
tomorrow, so that I'm not just speculating.
To again emphasise this: there is no single container which is _not_ broken for EAR right
now the one way or the other. We could of course keep this backward compatible ;)
LieGrue,
strub
----- Original Message -----
> From: Pete Muir <pmuir(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: Joseph Bergmark <bergmark(a)us.ibm.com>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)lists.jboss.org>
> Sent: Monday, November 26, 2012 9:47 PM
> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>
>
> On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>
>>> 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.
>
> Right. Weld never sets the TCCL. But other things such as EJB might to in JBoss
> AS. Stuart, can you comment?
>
3:30 p.m.
On 26 Nov 2012, at 21:28, Pete Muir wrote:
On 26 Nov 2012, at 21:12, Mark Struberg wrote:
> As Joe already mentioned, maybe we should split this into EJBs with CDI annotations
on them and 'pure CDI beans'?
>
> In the case of pure CDI beans like @Dependent or JSR-330 beans - basically all beans
without a proxy - I have no clue where one would do the TCCL switch.
Agreed.
BTW I would strongly encourage any implementation to do this without resorting to fiddling
with the TCCL, this is a risky approach, and one that is confusing for sure.
>
>> I read what Jozef said to mean "It's not correct ...". And he is
>> correct, as he says Weld does behave like (b) in edge cases, however it
>> certainly doesn't behave like (b) in mainstream cases.
>
> Show off, Pete ;)
I'm not sure what you mean here. I was simply saying that I hadn't had the same
inference you had from Jozef's comment.
> I already published a few examples for @Specializes, @Alternatives and could easily
add @Decorator and @Interceptor examples. All show 1.(b) behaviour on Weld, GlassFish,
JBossAS, etc. I'm still missing a single example where it's a clear 1.(a) in an
EAR scenario..
Sure, the more examples we have the better!
I'll check with Jozef exactly where Weld does and doesn't follow the 1(a)
behavior tomorrow, so that I'm not just speculating.
>
> To again emphasise this: there is no single container which is _not_ broken for EAR
right now the one way or the other. We could of course keep this backward compatible ;)
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Pete Muir <pmuir(a)redhat.com>
>> To: Mark Struberg <struberg(a)yahoo.de>
>> Cc: Joseph Bergmark <bergmark(a)us.ibm.com>;
"cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>> Sent: Monday, November 26, 2012 9:47 PM
>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>
>>
>> On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>>
>>>> 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.
>>
>> Right. Weld never sets the TCCL. But other things such as EJB might to in JBoss
>> AS. Stuart, can you comment?
>>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
9:33 a.m.
On 11/26/2012 10:28 PM, Pete Muir wrote:
On 26 Nov 2012, at 21:12, Mark Struberg wrote:
> As Joe already mentioned, maybe we should split this into EJBs with CDI annotations
on them and 'pure CDI beans'?
>
> In the case of pure CDI beans like @Dependent or JSR-330 beans - basically all beans
without a proxy - I have no clue where one would do the TCCL switch.
Agreed.
>> I read what Jozef said to mean "It's not correct ...". And he is
>> correct, as he says Weld does behave like (b) in edge cases, however it
>> certainly doesn't behave like (b) in mainstream cases.
> Show off, Pete ;)
I'm not sure what you mean here. I was simply saying that I hadn't had the same
inference you had from Jozef's comment.
> I already published a few examples for @Specializes, @Alternatives and could easily
add @Decorator and @Interceptor examples. All show 1.(b) behaviour on Weld, GlassFish,
JBossAS, etc. I'm still missing a single example where it's a clear 1.(a) in an
EAR scenario..
Sure, the more examples we have the better!
I'll check with Jozef exactly where Weld does and doesn't follow the 1(a)
behavior tomorrow, so that I'm not just speculating.
It's enough to use
Mark's example and replace the specializing bean with
an alternative. Or add another web archive. You do not really have to do
much to find out that Mark's argument is a side-effect of the Weld bug I
already mentioned that affects a certain portion of usecases. Other than
that the containers do not have anything in common with 1(b).
> To again emphasise this: there is no single container which is _not_ broken for EAR
right now the one way or the other. We could of course keep this backward compatible ;)
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Pete Muir <pmuir(a)redhat.com>
>> To: Mark Struberg <struberg(a)yahoo.de>
>> Cc: Joseph Bergmark <bergmark(a)us.ibm.com>;
"cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>> Sent: Monday, November 26, 2012 9:47 PM
>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>
>>
>> On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>>
>>>> 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.
>>
>> Right. Weld never sets the TCCL. But other things such as EJB might to in JBoss
>> AS. Stuart, can you comment?
>>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
9:46 a.m.
It's enough to use Mark's example and replace the
specializing bean with
an alternative. Or add another web archive. You do not really have to do
much to find out that Mark's argument is a side-effect of the Weld bug I
already mentioned that affects a certain portion of usecases. Other than
that the containers do not have anything in common with 1(b).
Jozef, please don't add any personal interpretation but purely stick to the facts!
ALL the tested cases act like 1.(a) in ALL TESTED AND CERTIFIED EE6 servers so far!
To change this now will imo introduce backward incompatibility!
If you like it or not is another story. But please stick to the facts!
LieGrue,
strub
----- Original Message -----
From: Jozef Hartinger <jharting(a)redhat.com>
To: Pete Muir <pmuir(a)redhat.com>
Cc: Mark Struberg <struberg(a)yahoo.de>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)lists.jboss.org>
Sent: Tuesday, November 27, 2012 4:33 PM
Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
On 11/26/2012 10:28 PM, Pete Muir wrote:
> On 26 Nov 2012, at 21:12, Mark Struberg wrote:
>
>> As Joe already mentioned, maybe we should split this into EJBs with CDI
annotations on them and 'pure CDI beans'?
>>
>> In the case of pure CDI beans like @Dependent or JSR-330 beans -
basically all beans without a proxy - I have no clue where one would do the TCCL
switch.
> Agreed.
>
>>> I read what Jozef said to mean "It's not correct
...". And he is
>>> correct, as he says Weld does behave like (b) in edge cases,
however it
>>> certainly doesn't behave like (b) in mainstream cases.
>> Show off, Pete ;)
> I'm not sure what you mean here. I was simply saying that I hadn't
had the same inference you had from Jozef's comment.
>
>> I already published a few examples for @Specializes, @Alternatives and
could easily add @Decorator and @Interceptor examples. All show 1.(b) behaviour
on Weld, GlassFish, JBossAS, etc. I'm still missing a single example where
it's a clear 1.(a) in an EAR scenario..
> Sure, the more examples we have the better!
>
> I'll check with Jozef exactly where Weld does and doesn't follow
the 1(a) behavior tomorrow, so that I'm not just speculating.
It's enough to use Mark's example and replace the specializing bean with
an alternative. Or add another web archive. You do not really have to do
much to find out that Mark's argument is a side-effect of the Weld bug I
already mentioned that affects a certain portion of usecases. Other than
that the containers do not have anything in common with 1(b).
>
>> To again emphasise this: there is no single container which is _not_
broken for EAR right now the one way or the other. We could of course keep this
backward compatible ;)
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Pete Muir <pmuir(a)redhat.com>
>>> To: Mark Struberg <struberg(a)yahoo.de>
>>> Cc: Joseph Bergmark <bergmark(a)us.ibm.com>;
"cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>> Sent: Monday, November 26, 2012 9:47 PM
>>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>>
>>>
>>> On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>>>
>>>>> 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.
>>>
>>> Right. Weld never sets the TCCL. But other things such as EJB might
to in JBoss
>>> AS. Stuart, can you comment?
>>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
10:09 a.m.
These are facts. You claim that all the certified application servers
implement 1(b). You support this by providing a single testcase. There
are other testcases that show the opposite and indicate that what you
observe is not "application servers implementing 1(b)" but rather
"application servers behaving the 1(b) way in a limited portion of
scenarios, the 1(a) way in other portion of scenarios and there are also
scenarios where each application server behaves differently".
On 11/27/2012 04:46 PM, Mark Struberg wrote:
> It's enough to use Mark's example and replace the
specializing bean with
> an alternative. Or add another web archive. You do not really have to do
> much to find out that Mark's argument is a side-effect of the Weld bug I
> already mentioned that affects a certain portion of usecases. Other than
> that the containers do not have anything in common with 1(b).
Jozef, please don't add any personal interpretation but purely stick to the facts!
ALL the tested cases act like 1.(a) in ALL TESTED AND CERTIFIED EE6 servers so far!
To change this now will imo introduce backward incompatibility!
If you like it or not is another story. But please stick to the facts!
LieGrue,
strub
----- Original Message -----
> From: Jozef Hartinger <jharting(a)redhat.com>
> To: Pete Muir <pmuir(a)redhat.com>
> Cc: Mark Struberg <struberg(a)yahoo.de>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)lists.jboss.org>
> Sent: Tuesday, November 27, 2012 4:33 PM
> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>
> On 11/26/2012 10:28 PM, Pete Muir wrote:
>> On 26 Nov 2012, at 21:12, Mark Struberg wrote:
>>
>>> As Joe already mentioned, maybe we should split this into EJBs with CDI
> annotations on them and 'pure CDI beans'?
>>> In the case of pure CDI beans like @Dependent or JSR-330 beans -
> basically all beans without a proxy - I have no clue where one would do the TCCL
> switch.
>> Agreed.
>>
>>>> I read what Jozef said to mean "It's not correct
> ...". And he is
>>>> correct, as he says Weld does behave like (b) in edge cases,
> however it
>>>> certainly doesn't behave like (b) in mainstream cases.
>>> Show off, Pete ;)
>> I'm not sure what you mean here. I was simply saying that I hadn't
> had the same inference you had from Jozef's comment.
>>> I already published a few examples for @Specializes, @Alternatives and
> could easily add @Decorator and @Interceptor examples. All show 1.(b) behaviour
> on Weld, GlassFish, JBossAS, etc. I'm still missing a single example where
> it's a clear 1.(a) in an EAR scenario..
>> Sure, the more examples we have the better!
>>
>> I'll check with Jozef exactly where Weld does and doesn't follow
> the 1(a) behavior tomorrow, so that I'm not just speculating.
> It's enough to use Mark's example and replace the specializing bean with
>
> an alternative. Or add another web archive. You do not really have to do
> much to find out that Mark's argument is a side-effect of the Weld bug I
> already mentioned that affects a certain portion of usecases. Other than
> that the containers do not have anything in common with 1(b).
>>> To again emphasise this: there is no single container which is _not_
> broken for EAR right now the one way or the other. We could of course keep this
> backward compatible ;)
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Pete Muir <pmuir(a)redhat.com>
>>>> To: Mark Struberg <struberg(a)yahoo.de>
>>>> Cc: Joseph Bergmark <bergmark(a)us.ibm.com>;
> "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>>> Sent: Monday, November 26, 2012 9:47 PM
>>>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>>>
>>>>
>>>> On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>>>>
>>>>>> 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.
>>>>
>>>> Right. Weld never sets the TCCL. But other things such as EJB might
> to in JBoss
>>>> AS. Stuart, can you comment?
>>>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
10:36 a.m.
We have 4 tests which all show 1 (b) and we have zero tests which show 1 (a).
As I told you almost a month ago: provide tests which prove your claim and then we can
verify. You always claimed 1 (a) and I proved all your claims wrong so far. It's still
your turn to provide tests which underline your claims. Until then it's just mere
believe and not a fact.
LieGrue,
strub
----- Original Message -----
From: Jozef Hartinger <jharting(a)redhat.com>
To: Mark Struberg <struberg(a)yahoo.de>
Cc: Pete Muir <pmuir(a)redhat.com>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)lists.jboss.org>
Sent: Tuesday, November 27, 2012 5:09 PM
Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
T hese are facts. You claim that all the certified application servers
implement 1(b). You support this by providing a single testcase. There
are other testcases that show the opposite and indicate that what you
observe is not "application servers implementing 1(b)" but rather
"application servers behaving the 1(b) way in a limited portion of
scenarios, the 1(a) way in other portion of scenarios and there are also
scenarios where each application server behaves differently".
On 11/27/2012 04:46 PM, Mark Struberg wrote:
>> It's enough to use Mark's example and replace the specializing
bean with
>> an alternative. Or add another web archive. You do not really have to
do
>> much to find out that Mark's argument is a side-effect of the Weld
bug I
>> already mentioned that affects a certain portion of usecases. Other
than
>> that the containers do not have anything in common with 1(b).
> Jozef, please don't add any personal interpretation but purely stick to
the facts!
>
> ALL the tested cases act like 1.(a) in ALL TESTED AND CERTIFIED EE6
servers so far!
>
> To change this now will imo introduce backward incompatibility!
>
> If you like it or not is another story. But please stick to the facts!
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Jozef Hartinger <jharting(a)redhat.com>
>> To: Pete Muir <pmuir(a)redhat.com>
>> Cc: Mark Struberg <struberg(a)yahoo.de>;
"cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>> Sent: Tuesday, November 27, 2012 4:33 PM
>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>
>> On 11/26/2012 10:28 PM, Pete Muir wrote:
>>> On 26 Nov 2012, at 21:12, Mark Struberg wrote:
>>>
>>>> As Joe already mentioned, maybe we should split this into
EJBs with CDI
>> annotations on them and 'pure CDI beans'?
>>>> In the case of pure CDI beans like @Dependent or JSR-330
beans -
>> basically all beans without a proxy - I have no clue where one would do
the TCCL
>> switch.
>>> Agreed.
>>>
>>>>> I read what Jozef said to mean "It's not correct
>> ...". And he is
>>>>> correct, as he says Weld does behave like (b) in edge
cases,
>> however it
>>>>> certainly doesn't behave like (b) in mainstream
cases.
>>>> Show off, Pete ;)
>>> I'm not sure what you mean here. I was simply saying that I
hadn't
>> had the same inference you had from Jozef's comment.
>>>> I already published a few examples for @Specializes,
@Alternatives and
>> could easily add @Decorator and @Interceptor examples. All show 1.(b)
behaviour
>> on Weld, GlassFish, JBossAS, etc. I'm still missing a single
example where
>> it's a clear 1.(a) in an EAR scenario..
>>> Sure, the more examples we have the better!
>>>
>>> I'll check with Jozef exactly where Weld does and doesn't
follow
>> the 1(a) behavior tomorrow, so that I'm not just speculating.
>> It's enough to use Mark's example and replace the specializing
bean with
>>
>> an alternative. Or add another web archive. You do not really have to
do
>> much to find out that Mark's argument is a side-effect of the Weld
bug I
>> already mentioned that affects a certain portion of usecases. Other
than
>> that the containers do not have anything in common with 1(b).
>>>> To again emphasise this: there is no single container which
is _not_
>> broken for EAR right now the one way or the other. We could of course
keep this
>> backward compatible ;)
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Pete Muir <pmuir(a)redhat.com>
>>>>> To: Mark Struberg <struberg(a)yahoo.de>
>>>>> Cc: Joseph Bergmark <bergmark(a)us.ibm.com>;
>> "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>>>> Sent: Monday, November 26, 2012 9:47 PM
>>>>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and
visibility
>>>>>
>>>>>
>>>>> On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>>>>>
>>>>>>> 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.
>>>>>
>>>>> Right. Weld never sets the TCCL. But other things such as
EJB might
>> to in JBoss
>>>>> AS. Stuart, can you comment?
>>>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
3:02 a.m.
On 11/27/2012 05:36 PM, Mark Struberg wrote:
We have 4 tests which all show 1 (b) and we have zero tests which
show 1 (a).
Which are the 4? I am only aware of
https://github.com/struberg/cdi_eartest
As I told you almost a month ago: provide tests which prove your claim and then we can
verify. You always claimed 1 (a) and I proved all your claims wrong so far. It's still
your turn to provide tests which underline your claims. Until then it's just mere
believe and not a fact.
Even in this e-mail thread I already said how to change your
testcase to
see your theory fall apart. You can easily test that yourself.
LieGrue,
strub
----- Original Message -----
> From: Jozef Hartinger <jharting(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: Pete Muir <pmuir(a)redhat.com>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)lists.jboss.org>
> Sent: Tuesday, November 27, 2012 5:09 PM
> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>
> T hese are facts. You claim that all the certified application servers
> implement 1(b). You support this by providing a single testcase. There
> are other testcases that show the opposite and indicate that what you
> observe is not "application servers implementing 1(b)" but rather
> "application servers behaving the 1(b) way in a limited portion of
> scenarios, the 1(a) way in other portion of scenarios and there are also
> scenarios where each application server behaves differently".
>
> On 11/27/2012 04:46 PM, Mark Struberg wrote:
>>> It's enough to use Mark's example and replace the specializing
> bean with
>>> an alternative. Or add another web archive. You do not really have to
> do
>>> much to find out that Mark's argument is a side-effect of the Weld
> bug I
>>> already mentioned that affects a certain portion of usecases. Other
> than
>>> that the containers do not have anything in common with 1(b).
>> Jozef, please don't add any personal interpretation but purely stick to
> the facts!
>> ALL the tested cases act like 1.(a) in ALL TESTED AND CERTIFIED EE6
> servers so far!
>> To change this now will imo introduce backward incompatibility!
>>
>> If you like it or not is another story. But please stick to the facts!
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Jozef Hartinger <jharting(a)redhat.com>
>>> To: Pete Muir <pmuir(a)redhat.com>
>>> Cc: Mark Struberg <struberg(a)yahoo.de>;
> "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>> Sent: Tuesday, November 27, 2012 4:33 PM
>>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>>
>>> On 11/26/2012 10:28 PM, Pete Muir wrote:
>>>> On 26 Nov 2012, at 21:12, Mark Struberg wrote:
>>>>
>>>>> As Joe already mentioned, maybe we should split this into
> EJBs with CDI
>>> annotations on them and 'pure CDI beans'?
>>>>> In the case of pure CDI beans like @Dependent or JSR-330
> beans -
>>> basically all beans without a proxy - I have no clue where one would do
> the TCCL
>>> switch.
>>>> Agreed.
>>>>
>>>>>> I read what Jozef said to mean "It's not correct
>>> ...". And he is
>>>>>> correct, as he says Weld does behave like (b) in edge
> cases,
>>> however it
>>>>>> certainly doesn't behave like (b) in mainstream
> cases.
>>>>> Show off, Pete ;)
>>>> I'm not sure what you mean here. I was simply saying that I
> hadn't
>>> had the same inference you had from Jozef's comment.
>>>>> I already published a few examples for @Specializes,
> @Alternatives and
>>> could easily add @Decorator and @Interceptor examples. All show 1.(b)
> behaviour
>>> on Weld, GlassFish, JBossAS, etc. I'm still missing a single
> example where
>>> it's a clear 1.(a) in an EAR scenario..
>>>> Sure, the more examples we have the better!
>>>>
>>>> I'll check with Jozef exactly where Weld does and doesn't
> follow
>>> the 1(a) behavior tomorrow, so that I'm not just speculating.
>>> It's enough to use Mark's example and replace the specializing
> bean with
>>> an alternative. Or add another web archive. You do not really have to
> do
>>> much to find out that Mark's argument is a side-effect of the Weld
> bug I
>>> already mentioned that affects a certain portion of usecases. Other
> than
>>> that the containers do not have anything in common with 1(b).
>>>>> To again emphasise this: there is no single container which
> is _not_
>>> broken for EAR right now the one way or the other. We could of course
> keep this
>>> backward compatible ;)
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Pete Muir <pmuir(a)redhat.com>
>>>>>> To: Mark Struberg <struberg(a)yahoo.de>
>>>>>> Cc: Joseph Bergmark <bergmark(a)us.ibm.com>;
>>> "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>>>>> Sent: Monday, November 26, 2012 9:47 PM
>>>>>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and
> visibility
>>>>>>
>>>>>> On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>> Right. Weld never sets the TCCL. But other things such as
> EJB might
>>> to in JBoss
>>>>>> AS. Stuart, can you comment?
>>>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
4:42 p.m.
Antoine Sabot-Durand votes : 1a and 2a.
Le 29 nov. 2012 à 10:02, Jozef Hartinger <jharting(a)redhat.com> a écrit :
On 11/27/2012 05:36 PM, Mark Struberg wrote:
> We have 4 tests which all show 1 (b) and we have zero tests which show 1 (a).
Which are the 4? I am only aware of https://github.com/struberg/cdi_eartest
>
>
> As I told you almost a month ago: provide tests which prove your claim and then we
can verify. You always claimed 1 (a) and I proved all your claims wrong so far. It's
still your turn to provide tests which underline your claims. Until then it's just
mere believe and not a fact.
Even in this e-mail thread I already said how to change your testcase to
see your theory fall apart. You can easily test that yourself.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Jozef Hartinger <jharting(a)redhat.com>
>> To: Mark Struberg <struberg(a)yahoo.de>
>> Cc: Pete Muir <pmuir(a)redhat.com>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)lists.jboss.org>
>> Sent: Tuesday, November 27, 2012 5:09 PM
>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>
>> T hese are facts. You claim that all the certified application servers
>> implement 1(b). You support this by providing a single testcase. There
>> are other testcases that show the opposite and indicate that what you
>> observe is not "application servers implementing 1(b)" but rather
>> "application servers behaving the 1(b) way in a limited portion of
>> scenarios, the 1(a) way in other portion of scenarios and there are also
>> scenarios where each application server behaves differently".
>>
>> On 11/27/2012 04:46 PM, Mark Struberg wrote:
>>>> It's enough to use Mark's example and replace the specializing
>> bean with
>>>> an alternative. Or add another web archive. You do not really have to
>> do
>>>> much to find out that Mark's argument is a side-effect of the Weld
>> bug I
>>>> already mentioned that affects a certain portion of usecases. Other
>> than
>>>> that the containers do not have anything in common with 1(b).
>>> Jozef, please don't add any personal interpretation but purely stick to
>> the facts!
>>> ALL the tested cases act like 1.(a) in ALL TESTED AND CERTIFIED EE6
>> servers so far!
>>> To change this now will imo introduce backward incompatibility!
>>>
>>> If you like it or not is another story. But please stick to the facts!
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Jozef Hartinger <jharting(a)redhat.com>
>>>> To: Pete Muir <pmuir(a)redhat.com>
>>>> Cc: Mark Struberg <struberg(a)yahoo.de>;
>> "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>>> Sent: Tuesday, November 27, 2012 4:33 PM
>>>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>>>
>>>> On 11/26/2012 10:28 PM, Pete Muir wrote:
>>>>> On 26 Nov 2012, at 21:12, Mark Struberg wrote:
>>>>>
>>>>>> As Joe already mentioned, maybe we should split this into
>> EJBs with CDI
>>>> annotations on them and 'pure CDI beans'?
>>>>>> In the case of pure CDI beans like @Dependent or JSR-330
>> beans -
>>>> basically all beans without a proxy - I have no clue where one would do
>> the TCCL
>>>> switch.
>>>>> Agreed.
>>>>>
>>>>>>> I read what Jozef said to mean "It's not correct
>>>> ...". And he is
>>>>>>> correct, as he says Weld does behave like (b) in edge
>> cases,
>>>> however it
>>>>>>> certainly doesn't behave like (b) in mainstream
>> cases.
>>>>>> Show off, Pete ;)
>>>>> I'm not sure what you mean here. I was simply saying that I
>> hadn't
>>>> had the same inference you had from Jozef's comment.
>>>>>> I already published a few examples for @Specializes,
>> @Alternatives and
>>>> could easily add @Decorator and @Interceptor examples. All show 1.(b)
>> behaviour
>>>> on Weld, GlassFish, JBossAS, etc. I'm still missing a single
>> example where
>>>> it's a clear 1.(a) in an EAR scenario..
>>>>> Sure, the more examples we have the better!
>>>>>
>>>>> I'll check with Jozef exactly where Weld does and doesn't
>> follow
>>>> the 1(a) behavior tomorrow, so that I'm not just speculating.
>>>> It's enough to use Mark's example and replace the specializing
>> bean with
>>>> an alternative. Or add another web archive. You do not really have to
>> do
>>>> much to find out that Mark's argument is a side-effect of the Weld
>> bug I
>>>> already mentioned that affects a certain portion of usecases. Other
>> than
>>>> that the containers do not have anything in common with 1(b).
>>>>>> To again emphasise this: there is no single container which
>> is _not_
>>>> broken for EAR right now the one way or the other. We could of course
>> keep this
>>>> backward compatible ;)
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: Pete Muir <pmuir(a)redhat.com>
>>>>>>> To: Mark Struberg <struberg(a)yahoo.de>
>>>>>>> Cc: Joseph Bergmark <bergmark(a)us.ibm.com>;
>>>> "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>>>>>> Sent: Monday, November 26, 2012 9:47 PM
>>>>>>> Subject: Re: [cdi-dev] [Vote] @ApplicationScoped and
>> visibility
>>>>>>>
>>>>>>> On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>>>>>>>
>>>>>>>>> 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.
>>>>>>>
>>>>>>> Right. Weld never sets the TCCL. But other things such as
>> EJB might
>>>> to in JBoss
>>>>>>> AS. Stuart, can you comment?
>>>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
4:11 p.m.
In AS7 we set the TCCL on each EJB invocation. There is no explicit requirement to do this
is in the EJB spec as far as I can see, however I can't really imagine an
implementation not doing this, as you could potentially end up with a TCCL that cannot see
the EJB class.
Stuart
Pete Muir wrote:
On 26 Nov 2012, at 19:41, Mark Struberg wrote:
>> 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.
Right. Weld never sets the TCCL. But other things such as EJB might to in JBoss AS.
Stuart, can you comment?
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
8:31 a.m.
Oracle votes (a) for both 1 and 2.
On 11/26/2012 08:44 AM, Pete Muir wrote:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
9:01 a.m.
Daniel Sachse votes: 1a and 2a.
Am 28.11.2012 um 15:31 schrieb JJ Snyder <j.j.snyder(a)oracle.com>:
Oracle votes (a) for both 1 and 2.
On 11/26/2012 08:44 AM, Pete Muir wrote:
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
9:06 a.m.
Many thanks for voting all.
Results are:
No vote: 3
1a: 6
1b: 1
2a: 6
2b: 1
With this in mind, I will draft up the changes to implement 1a and 2a in the spec.
Pete
On 26 Nov 2012, at 13:44, Pete Muir wrote:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
4401
days inactive
4408
days old
20 comments
8 participants
participants (8)
-
Daniel Sachse -
JJ Snyder -
Joseph Bergmark -
Jozef Hartinger -
Mark Struberg -
Pete Muir -
Sabot-Durand Antoine -
Stuart Douglas