[cdi-dev] [Vote] @ApplicationScoped and visibility
Mark Struberg
struberg at yahoo.de
Mon Nov 26 16:12:20 EST 2012
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 at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: Joseph Bergmark <bergmark at us.ibm.com>; "cdi-dev at lists.jboss.org" <cdi-dev at 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?
>
More information about the cdi-dev
mailing list