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

Pete Muir pmuir at redhat.com
Tue Nov 27 06:55:39 EST 2012


Agreed. However, this actually followed on from Joe's comment (which you said he was wrong about) "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." - which is certainly true in JBoss AS, as Stuart said, and I assume as Joe said it, it's true in Websphere too.

On 26 Nov 2012, at 22:36, Mark Struberg wrote:

> 
> 
> perfectly fine for EJBs. But we are talking about CDI and not about EJB!
> 
> I've seen no single CDI container doing this so far.
> 
> 
> ------------------------------
> Stuart Douglas schrieb am Mo., 26. Nov 2012 14:11 PST:
> 
>> In AS7 we set the TCCL on each EJB invocation. There is no explicit requirement to do this is in the EJB spec as far as I can see, however I can't really imagine an implementation not doing this, as you could potentially end up with a TCCL that cannot see the EJB class. 
>> 
>> Stuart
>> 
>> 
>> Pete Muir wrote:
>>> 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