Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
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?