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

Ales Justin ajustin at redhat.com
Wed Dec 21 11:00:27 EST 2011 

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

On Dec 15, 2011, at 9:35 PM, Arne Limburg wrote:

> 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

More information about the cdi-dev mailing list