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

[Mark Struberg]

The BDA stuff is not only broken for @Alternatives, but also for <interceptors> and <decorators>

Plus: @Specializes is NOT affected by BDA as per CDI-1.0. But still gets hit by class visibility issues.


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.


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 11:14 AM
> Subject: Re: [cdi-dev] easy solution for class visibility checks?
> 
> I'm somewhat warped by the way we wrote Weld, but I can see a number of 
> flaws:
> 
> 1) This moves the onus of determining class visibility away from the container 
> (which does know about class visibility) and (possibly) onto a portable 
> extension author.
> 
> This alone is sufficient to make it unworkable IMO.
> 
> 2) This decouples class visibility from the resolution process which is where 
> it's really important
> 
> 3) Currently we don't define the exact semantics of this integration point, 
> which allows an implementation freedom in how to implement it (OWB could use an 
> interrogative approach today should it wish, Weld could use a push based 
> approach where this info is pushed to Weld).
> 
> So far, I'm unconvinced there is a fundamental problem with the way bean 
> archives work, and that they provide a good abstraction over class visibility 
> rules and class loading schemes. There are some unfortunate side effects where 
> it impacts with other concerns (e.g. alternatives) that we all know well. So, I 
> would prefer we concentrate on fixing these bad interactions (which would still 
> exist with any abstraction over class loading schemes) than try to change our 
> abstraction over class loading scheme.
> 
> On 15 Dec 2011, at 07:40, Mark Struberg wrote:
> 
>> 
>> 
>>  Hi folks!
>> 
>>  I just had an idea which is so simple that I just cannot believe it! 
>> 
>>  So please review and ping me if I missed something.
>> 
>>  This topic is related to CDI-18 (BDA dropping) and CDI-129 
> (@EnterpriseApplicationScoped)
>> 
>> 
>>  What is the problem with CDI-1.0?
>> 
>>  Well, CDI-1.0 says nothing about class visibility, but instead tries to 
> solve all those issues by introducing the BeanDefinitionArchive (BDA). This in 
> turn creates more harm than good. 
>> 
>> 
>>  An example of such a broken use case would be that it is currently allowed 
> to have a  public class @Singleton MyService {} residing in shared EAR jar being 
> @Specialized by a  public class @Singleton MySpecializedService extends 
> MyService {} residing in WEB-INF/classes of one single webapp.
>>  Obviously (with a JSR-316 conform 'sane' classloader hierarchy set 
> up) this will not work. Because MySpecializedService is not visible from the EAR 
> nor the other webapps (because of the ClassLoader isolation).
>> 
>>  In CDI-18 I proposed to add the following rules:
>> 
>>>  The container must ensure that for any 
>>>      * @Specializes @NScoped class Y extends X and
>>>      * @Alternative @NScoped class Y implements X
>>>  class Y is accessible by all classes which can access X in the same 
> @NScoped context.
>> 
>>  The problem now is: how does a custom 3rd party scope determine those 
> rules?
>>  Because the issue is not only valid for @EnterpriseApplicationScoped. Just 
> imagine to add a @SystemScoped which is a singleton-per-JVM (residing in the 
> System or extension ClassLoader), or a @ClusterScoped, ...
>> 
>> 
>>  Today I realized that the *only* relevant thing is actually if the context 
> maintaining the scope of 'class Y' (see definition above) can see the 
> class Y.
>> 
>>  It is just not valid to write a @EnterpriseApplicationScoped public class 
> MyService if the EnterpriseApplicationScopedContext cannot see MyService.
>> 
>>  The easiest solution would be to add a method to Context which checks the 
> visibility at startup:
>> 
>>  boolean isVisible(Class beanClass) or 
>>  boolean isVisible(String className)  (need to think about which one works 
> better, esp with different scenarios)
>> 
>>  Of course since #addContext is only in AfterBeanDiscovery, we need to do 
> this in some 'verifyDeployment' phase after the bean scanning.
>> 
>>  wdyt? 
>> 
>>  Is the intention clear? Or should I bring more samples about how that would 
> work? 
>> 
>>  Is there any flaw in there which I have overlooked?
>> 
>> 
>>  LieGrue,
>>  strub
>> 
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>