Hi,
But Mark’s idea is good anyway. Couldn’t that check be made by the container? The spec just would need to write down the visibility-rules.
It seems to have to do something with the classloader of the Context and the classloader of the bean type.
Something like “A bean is visible to a context if the bean-class is the same (meanding Object identity) as the class of the same name that is returned by the classloader of the Context-Instance”
Cheers,
Arne
Von: cdi-dev-bounces@lists.jboss.org [mailto:cdi-dev-bounces@lists.jboss.org] Im Auftrag von Fabien Marsaud
Gesendet: Donnerstag, 15. Dezember 2011 13:20
An: Mark Struberg
Cc: cdi-dev
Betreff: Re: [cdi-dev] easy solution for class visibility checks?
>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@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@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