[cdi-dev] [Vote] @ApplicationScoped and visibility
Jozef Hartinger
jharting at redhat.com
Thu Nov 29 04:02:19 EST 2012
On 11/27/2012 05:36 PM, Mark Struberg wrote:
> We have 4 tests which all show 1 (b) and we have zero tests which show 1 (a).
Which are the 4? I am only aware of https://github.com/struberg/cdi_eartest
>
>
> 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.
Even in this e-mail thread I already said how to change your testcase to
see your theory fall apart. You can easily test that yourself.
>
> 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
More information about the cdi-dev
mailing list