4:14 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev