[cdi-dev] easy solution for class visibility checks?

[Mark Struberg]

another point is that currently 1 BDA == 1 single jar file (or WEB-INF/classes)


But that's just way too restrictive imo. IF, then it should treat all jars/classes in the same webapp as 1 BDA and all shared EAR jars as another BDA.
But still then, there is a lot left undefined. Imo all the BDA stuff is not worth the pita.


> Good point. There is definitely a shared responsibility though here, and I'm 
> not sure we can shift all responsibility to the context.

Yup, I also don't really like it to make the Contexts responsible alone, because it might make it harder to implement portable Contexts.
Otoh it's pretty pragmatic and is doable in all situations I knew.

Maybe we can collect samples (use-cases) and play with them?

LieGrue,
strub



----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Thursday, December 15, 2011 12:14 PM
> Subject: Re: [cdi-dev] easy solution for class visibility checks?
> 
> 
> On 15 Dec 2011, at 11:10, Mark Struberg wrote:
> 
>>  The BDA stuff is not only broken for @Alternatives, but also for 
> <interceptors> and <decorators>
> 
> Right, I wrote e.g. not i.e. ;-) Sorry, was just being lazy.
> 
>> 
>>  Plus: @Specializes is NOT affected by BDA as per CDI-1.0. But still gets 
> hit by class visibility issues.
> 
> Right, this is not right in the CDI spec.
> 
>> 
>> 
>>  Imo the container just cannot know whether a 3rd party Context is going to 
> use the ThreadContextClassLoader, the SystemClassloader, the 
> MyScoped.class.getClassLoader() etc. There is nothing a container can do about 
> it, because _only_ the Context knows where it will store it's stuff.
> 
> Good point. There is definitely a shared responsibility though here, and I'm 
> not sure we can shift all responsibility to the context.
>