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.
On Thu, Dec 15, 2011 at 12:28 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
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(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
http://www.suntriprecords.com