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(a)redhat.com>
To: Mark Struberg <struberg(a)yahoo.de>
Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev