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

[Mark Struberg]

> 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 at redhat.com>
> To: Pete Muir <pmuir at redhat.com>
> Cc: Mark Struberg <struberg at yahoo.de>; "cdi-dev at lists.jboss.org" <cdi-dev at 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 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?
>>>> 
>> 
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>