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

[Pete Muir]

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