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

Ales Justin ajustin at redhat.com
Tue Jan 3 14:36:30 EST 2012 

This is a dup from 23/12/2011, hence ignore -- already discussed.

> Sorry for pitching in so late.
> (been busy with hacking something similar for our Ceylon M1 :-)
> 
> Imho, I don't see how moving the visibility to either Context or Contextual will help.
> I'm more into Pete's favor (and w/o being bias), as there is no way on earth devs will know how to properly implement this in Context or Contextual.
> 
> I've stated this a few times already, I actually like BDA.
> It's probably just the lack of proper wording and listing *all* visibility rules (which is definitely hard, but hey this is *the* spec) in the spec that lead to issues that we see now.
> 
> You only get full visibility rules from CL hierarchy / wiring.
> But as we  all know the CL API doesn't expose anything about this hierarchy / wiring,
> hence the only one that knows this is the container, which needs a mechanism to abstract this - aka BDA.
> 
> This way you -- as it is now -- push the nitty-gritty CL details to container devs, not the users.
> And if you don't have exotic rules -- as we potentially had in MC -- implementing BDA is not that difficult.
> e.g. JEE is pretty straight forward, with only a few exceptions
> 
> Imo we just need to set better rules on alts, iceptors, decorators, specializes, etc.
> Or even extend the config, so the user can be even more explicit; e.g. force certain isolation, filtering, etc
> 
> -Ales
> 
>> Ok, as Mark mentioned: Our real problem with class-visibility is: What classloader will Contextual.create use to create the contextual. If we would know this, we could implement container-checks for class-visibility.
>> So from this comes another idea: What about adding a method getContextualClassLoader() to the Contextual interface? This method should return the classloader that will be used for instance-creation. The container then could check class-visibility for specializing beans, interceptors, decorators and so on.
>> 
>> Cheers,
>> Arne
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: cdi-dev-bounces at lists.jboss.org [mailto:cdi-dev-bounces at lists.jboss.org] Im Auftrag von Arne Limburg
>> Gesendet: Donnerstag, 15. Dezember 2011 14:16
>> An: Mark Struberg
>> Cc: cdi-dev
>> Betreff: Re: [cdi-dev] easy solution for class visibility checks?
>> 
>> OK, then the question is: How would you implement Context.isVisible? I'm pretty sure, that if your solution works, there would be a very generic implementation for it, that we could use to specify container-behavior. Sounds like it could work, but I still need to think about it...
>> 
>> Cheers,
>> Arne
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Mark Struberg [mailto:struberg at yahoo.de]
>> Gesendet: Donnerstag, 15. Dezember 2011 14:04
>> An: Arne Limburg; Fabien Marsaud
>> Cc: cdi-dev; Pete Muir
>> Betreff: Re: AW: [cdi-dev] easy solution for class visibility checks?
>> 
>> 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
>>> 
>>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

More information about the cdi-dev mailing list