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

[Pete Muir]

On 15 Dec 2011, at 11:28, Mark Struberg wrote:

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

I don't believe this is specified at all? If so where, I think this is wrong, and not the intent, and we just need to tweak the language a bit.

> 
> 
> 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.
>>