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

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

From: Jozef Hartinger <jharting(a)redhat.com&gt; To: Pete Muir <pmuir(a)redhat.com&gt; Cc: Mark Struberg <struberg(a)yahoo.de>; &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; 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&gt; >>> To: Mark Struberg <struberg(a)yahoo.de&gt; >>> Cc: Joseph Bergmark <bergmark(a)us.ibm.com>; &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; >>> 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