>Yup, I also don't really like it to make the Contexts responsible alone,
because it might make it harder to implement portable Contexts.
I was about to say the same. Usually a scope is straightforward:
@Scope @Retention @Target public @interface MyScope {}
But the context taking care of it has to drag the whole carriage: the beanstore, the 2 get() methods and the cleanup. This may be not tedious for you, but it definitely is for the average programmer (if he dares ot make it right, threadsafe, etc).
A visibility method would add more complications and give a serious opportunity to the developper to wreck havoc. There should be at least a default impl and/or a higher order instance taking care of the visibility things.
fm.
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.
Yup, I also don't really like it to make the Contexts responsible alone, because it might make it harder to implement portable Contexts.
> Good point. There is definitely a shared responsibility though here, and I'm
> not sure we can shift all responsibility to the context.
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@redhat.com>
> To: Mark Struberg <struberg@yahoo.de>
> Cc: cdi-dev <cdi-dev@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.
>
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev