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

[Mark Struberg]

Thought about that as well, but the problem is that the ClassLoader of a Context is most times irrellevant. 


E.g. for @RequestScoped, the RequestContext.class is still in weld.jar or owb-impl.jar which is in turn part of the very outermost container classloader.

The RequestContext never uses the RequestContext.class.getClassLoader but is just a Map<Bean<T>,T /*created via Bean<T>#create()*/>  


Maybe I'm also a bit too fixated on the way this stuff works in OWB (where we currently don't support EnterpriseApplicationScoped out of the box).

Because it's not only the Context, it's also the way how Contextual<T>#create works. Which ClassLoader does it take? 


*stillscratchingmyhead*

LieGrue,
strub

>________________________________
> From: Arne Limburg <arne.limburg at openknowledge.de>
>To: Fabien Marsaud <fabmars at gmail.com>; Mark Struberg <struberg at yahoo.de> 
>Cc: cdi-dev <cdi-dev at lists.jboss.org> 
>Sent: Thursday, December 15, 2011 1:29 PM
>Subject: AW: [cdi-dev] easy solution for class visibility checks?
> 
>
>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 at lists.jboss.org [mailto:cdi-dev-bounces at 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 at 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 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.
>>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
>-- 
>http://www.suntriprecords.com
>
>