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

[Mark Struberg]

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 at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: Pete Muir <pmuir at redhat.com>; "cdi-dev at lists.jboss.org" <cdi-dev at 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 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
>