1:40 a.m.
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
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
5:10 a.m.
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
5:14 a.m.
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.
5:28 a.m.
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(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)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.
>
6:20 a.m.
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(a)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(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
http://www.suntriprecords.com
6:29 a.m.
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(a)lists.jboss.org [mailto:cdi-dev-bounces@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@yahoo.de<mailto:struberg@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@redhat.com<mailto:pmuir@redhat.com>>
> To: Mark Struberg <struberg@yahoo.de<mailto:struberg@yahoo.de>>
> Cc: cdi-dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@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@lists.jboss.org<mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
http://www.suntriprecords.com
7:04 a.m.
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(a)openknowledge.de>
To: Fabien Marsaud <fabmars(a)gmail.com>; Mark Struberg <struberg(a)yahoo.de>
Cc: cdi-dev <cdi-dev(a)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@lists.jboss.org [mailto:cdi-dev-bounces@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(a)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(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
http://www.suntriprecords.com
7:16 a.m.
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@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(a)openknowledge.de>
To: Fabien Marsaud <fabmars(a)gmail.com>; Mark Struberg
<struberg(a)yahoo.de>
Cc: cdi-dev <cdi-dev(a)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@lists.jboss.org
[mailto:cdi-dev-bounces@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(a)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(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
http://www.suntriprecords.com
2:35 p.m.
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(a)lists.jboss.org [mailto:cdi-dev-bounces@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@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(a)openknowledge.de>
To: Fabien Marsaud <fabmars(a)gmail.com>; Mark Struberg
<struberg(a)yahoo.de>
Cc: cdi-dev <cdi-dev(a)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@lists.jboss.org
[mailto:cdi-dev-bounces@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(a)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(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
http://www.suntriprecords.com
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
9:54 a.m.
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
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(a)lists.jboss.org [mailto:cdi-dev-bounces@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@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(a)openknowledge.de>
> To: Fabien Marsaud <fabmars(a)gmail.com>; Mark Struberg
> <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)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@lists.jboss.org
> [mailto:cdi-dev-bounces@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(a)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(a)redhat.com>
>> To: Mark Struberg <struberg(a)yahoo.de>
>> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
> --
> http://www.suntriprecords.com
>
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
1:36 p.m.
This is a dup from 23/12/2011, hence ignore -- already discussed.
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
> 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(a)lists.jboss.org [mailto:cdi-dev-bounces@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@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(a)openknowledge.de>
>> To: Fabien Marsaud <fabmars(a)gmail.com>; Mark Struberg
>> <struberg(a)yahoo.de>
>> Cc: cdi-dev <cdi-dev(a)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@lists.jboss.org
>> [mailto:cdi-dev-bounces@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(a)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(a)redhat.com>
>>> To: Mark Struberg <struberg(a)yahoo.de>
>>> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>>
>> --
>> http://www.suntriprecords.com
>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
10 a.m.
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(a)lists.jboss.org [mailto:cdi-dev-bounces@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@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(a)openknowledge.de>
> To: Fabien Marsaud <fabmars(a)gmail.com>; Mark Struberg
> <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)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@lists.jboss.org
> [mailto:cdi-dev-bounces@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(a)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(a)redhat.com>
>> To: Mark Struberg <struberg(a)yahoo.de>
>> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
> --
> http://www.suntriprecords.com
>
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
5:08 p.m.
Yes, it's hard to get right - but the BDA is broken as well. I'd say it's even
more heavily broken than just letting it out.
1.) The major reason is that 1 jar == 1 BDA as per the current spec. This is just way too
restrictive and doesn't fit into any existing modularity system, because they either
split inside the jars (OSGi exported vs not exported) or way outside the BDA (all jars in
WEB-INF/lib of a webapp definitely belong to the same 'module'.
2.) A few CDI tricks don't recognize the BDA (e.g. @Specializes) but still will be
broken if they hit _real_ module boundaries. BDA is not a solution for those.
3.) 99% of all beans in Seam are annotated with @DefaultBean. Guess what this
'DefaultBean' does? It 'works around' the BDA restriction and thus breaks
a lots of things. Why? Because you cannot work with this BDA stuff in place. So while you
are telling me that BDA is the solution, your folks are blasting it away right now ;)
But I think we'll finally come up with a solution if we take the time.
LieGrue,
strub
----- Original Message -----
From: Ales Justin <ajustin(a)redhat.com>
To: cdi-dev <cdi-dev(a)lists.jboss.org>
Cc:
Sent: Wednesday, December 21, 2011 5:00 PM
Subject: Re: [cdi-dev] easy solution for class visibility checks?
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(a)lists.jboss.org
[mailto:cdi-dev-bounces@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@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(a)openknowledge.de>
>> To: Fabien Marsaud <fabmars(a)gmail.com>; Mark Struberg
>> <struberg(a)yahoo.de>
>> Cc: cdi-dev <cdi-dev(a)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@lists.jboss.org
>> [mailto:cdi-dev-bounces@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(a)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(a)redhat.com>
>>> To: Mark Struberg <struberg(a)yahoo.de>
>>> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>>
>> --
>> http://www.suntriprecords.com
>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
5:02 a.m.
Yes, it's hard to get right - but the BDA is broken as well.
Agreed, but I think the concept itself is not broken.
Just needs more thought into it.
I'd say it's even more heavily broken than just letting it
out.
As you yourself suggested - via another mechanism - we do need a mechanism to provide
proper visibility.
Flat out just won't work. It probably might for 95% cases, aka .war apps, but CDI is
more than just that.
1.) The major reason is that 1 jar == 1 BDA as per the current spec.
This is just way too restrictive and doesn't fit into any existing modularity system,
because they either split inside the jars (OSGi exported vs not exported)
OSGi still falls into 1 jar / 1 BDA. I don't see why not.
It's just a matter of integration with the OSGi system, letting you scan only truly
visible resources.
(or exposing the internals only through service pattern)
or way outside the BDA (all jars in WEB-INF/lib of a webapp
definitely belong to the same 'module'.
Why?
Each lib can be a CDI archive, hence its own BDA.
I do agree this falls out a bit of classic CL visibility/modularity.
But that's how the spec defines if, for a reason.
And it's not hard to follow, while inside a container -- CL defines the visibility
rules, presence of beans.xml defines the fine grained archives.
2.) A few CDI tricks don't recognize the BDA (e.g. @Specializes)
but still will be broken if they hit _real_ module boundaries. BDA is not a solution for
those.
Imo this is just a matter of better spec.
Putting natural rules into proper wording, which is what we're missing now - hence
this CDI JIRA issue(s).
3.) 99% of all beans in Seam are annotated with @DefaultBean. Guess
what this 'DefaultBean' does? It 'works around' the BDA restriction and
thus breaks a lots of things. Why? Because you cannot work with this BDA stuff in place.
So while you are telling me that BDA is the solution, your folks are blasting it away
right now ;)
I would guess - since I never used it - this was introduced due to AS6' BDA handling,
which was not the best.
But from what I worked with using CDI in "real" apps - and it's definitely
not a lot, since I don't do that for a living - I never had any issues wrt BDA usage
-- specially in AS7.
(ok, there was one, which I just recently fixed in 1.1.4.Final)
@DefaultBean is an exception not a rule, it proves nothing.
But I think we'll finally come up with a solution if we take the
time.
Yup.
-Ales
6:54 a.m.
On 22 Dec 2011, at 23:08, Mark Struberg wrote:
Yes, it's hard to get right - but the BDA is broken as well.
I'd say it's even more heavily broken than just letting it out.
1.) The major reason is that 1 jar == 1 BDA as per the current spec. This is just way too
restrictive and doesn't fit into any existing modularity system, because they either
split inside the jars (OSGi exported vs not exported) or way outside the BDA (all jars in
WEB-INF/lib of a webapp definitely belong to the same 'module'.
I don't interpret the spec like this, can you say why you come to this conclusion?
(spec sections/quotes)
2.) A few CDI tricks don't recognize the BDA (e.g. @Specializes) but still will be
broken if they hit _real_ module boundaries. BDA is not a solution for those.
I don't think this is a problem with bean archives, but with @Specializes.
3.) 99% of all beans in Seam are annotated with @DefaultBean. Guess what this
'DefaultBean' does? It 'works around' the BDA restriction and thus breaks
a lots of things. Why? Because you cannot work with this BDA stuff in place. So while you
are telling me that BDA is the solution, your folks are blasting it away right now ;)
No, it doesn't work around bean archives, it works around alternatives, which we all
know don't work too well from CDI 1.0.
So far you aren't convincing me that bean archives are broken, but that that
1) we have a problem with global enablement of alternatives (which we know)
2) we have a problem with @Specializes and modularity (which we know)
:-)
But I think we'll finally come up with a solution if we take the time.
LieGrue,
strub
----- Original Message -----
> From: Ales Justin <ajustin(a)redhat.com>
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Cc:
> Sent: Wednesday, December 21, 2011 5:00 PM
> Subject: Re: [cdi-dev] easy solution for class visibility checks?
>
> 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(a)lists.jboss.org
> [mailto:cdi-dev-bounces@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@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(a)openknowledge.de>
>>> To: Fabien Marsaud <fabmars(a)gmail.com>; Mark Struberg
>>> <struberg(a)yahoo.de>
>>> Cc: cdi-dev <cdi-dev(a)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@lists.jboss.org
>>> [mailto:cdi-dev-bounces@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(a)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(a)redhat.com>
>>>> To: Mark Struberg <struberg(a)yahoo.de>
>>>> Cc: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>
>>>
>>> --
>>> http://www.suntriprecords.com
>>>
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
10:09 a.m.
Imo the spec is pretty clear about BDAs:
12.1. Bean archives
Bean classes of enabled beans must be deployed in bean archives.
* A library jar, EJB jar, application client jar or rar archive is a bean archive if
it has a file named beans.xml in the
META-INF directory.
* The WEB-INF/classes directory of a war is a bean archive if there is a file named
beans.xml in the WEB-INF directory
of the war.
* A directory in the JVM classpath is a bean archive if it has a file named beans.xml
in the META-INF directory.
So this is pretty clear to me:"jar ... is a bean archive (BDA) if it has a file named
beans.xml..."
LieGrue,
strub
----- Original Message -----
From: Pete Muir <pmuir(a)redhat.com>
To: Mark Struberg <struberg(a)yahoo.de>
Cc: Ales Justin <ajustin(a)redhat.com>; cdi-dev <cdi-dev(a)lists.jboss.org>
Sent: Friday, December 23, 2011 1:54 PM
Subject: Re: [cdi-dev] easy solution for class visibility checks?
On 22 Dec 2011, at 23:08, Mark Struberg wrote:
> Yes, it's hard to get right - but the BDA is broken as well. I'd
say it's even more heavily broken than just letting it out.
>
> 1.) The major reason is that 1 jar == 1 BDA as per the current spec. This
is just way too restrictive and doesn't fit into any existing modularity
system, because they either split inside the jars (OSGi exported vs not
exported) or way outside the BDA (all jars in WEB-INF/lib of a webapp definitely
belong to the same 'module'.
I don't interpret the spec like this, can you say why you come to this
conclusion? (spec sections/quotes)
>
> 2.) A few CDI tricks don't recognize the BDA (e.g. @Specializes) but
still will be broken if they hit _real_ module boundaries. BDA is not a solution
for those.
I don't think this is a problem with bean archives, but with @Specializes.
>
>
> 3.) 99% of all beans in Seam are annotated with @DefaultBean. Guess what
this 'DefaultBean' does? It 'works around' the BDA restriction
and thus breaks a lots of things. Why? Because you cannot work with this BDA
stuff in place. So while you are telling me that BDA is the solution, your folks
are blasting it away right now ;)
No, it doesn't work around bean archives, it works around alternatives,
which we all know don't work too well from CDI 1.0.
So far you aren't convincing me that bean archives are broken, but that that
1) we have a problem with global enablement of alternatives (which we know)
2) we have a problem with @Specializes and modularity (which we know)
:-)
>
>
>
> But I think we'll finally come up with a solution if we take the time.
>
>
> LieGrue,
> strub
>
>
10:16 a.m.
I think I read this as "a jar is a bean archive" NOT "a bean archive is a
jar"… IOW it's requiring a jar to be a bean archive, but not vs versa, but I
think that is just my interpretation. So I think we need to tidy this language up for
sure, as I 100% agree this is too restrictive (and I always interpreted the spec to mean a
bean archive is a "module"). Can you file a JIRA so we don't loose this?
On 23 Dec 2011, at 16:09, Mark Struberg wrote:
Imo the spec is pretty clear about BDAs:
12.1. Bean archives
Bean classes of enabled beans must be deployed in bean archives.
* A library jar, EJB jar, application client jar or rar archive is a bean archive if
it has a file named beans.xml in the
META-INF directory.
* The WEB-INF/classes directory of a war is a bean archive if there is a file named
beans.xml in the WEB-INF directory
of the war.
* A directory in the JVM classpath is a bean archive if it has a file named beans.xml
in the META-INF directory.
So this is pretty clear to me:"jar ... is a bean archive (BDA) if it has a file
named beans.xml..."
LieGrue,
strub
----- Original Message -----
> From: Pete Muir <pmuir(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: Ales Justin <ajustin(a)redhat.com>; cdi-dev <cdi-dev(a)lists.jboss.org>
> Sent: Friday, December 23, 2011 1:54 PM
> Subject: Re: [cdi-dev] easy solution for class visibility checks?
>
>
> On 22 Dec 2011, at 23:08, Mark Struberg wrote:
>
>> Yes, it's hard to get right - but the BDA is broken as well. I'd
> say it's even more heavily broken than just letting it out.
>>
>> 1.) The major reason is that 1 jar == 1 BDA as per the current spec. This
> is just way too restrictive and doesn't fit into any existing modularity
> system, because they either split inside the jars (OSGi exported vs not
> exported) or way outside the BDA (all jars in WEB-INF/lib of a webapp definitely
> belong to the same 'module'.
>
> I don't interpret the spec like this, can you say why you come to this
> conclusion? (spec sections/quotes)
>
>>
>> 2.) A few CDI tricks don't recognize the BDA (e.g. @Specializes) but
> still will be broken if they hit _real_ module boundaries. BDA is not a solution
> for those.
>
> I don't think this is a problem with bean archives, but with @Specializes.
>
>>
>>
>> 3.) 99% of all beans in Seam are annotated with @DefaultBean. Guess what
> this 'DefaultBean' does? It 'works around' the BDA restriction
> and thus breaks a lots of things. Why? Because you cannot work with this BDA
> stuff in place. So while you are telling me that BDA is the solution, your folks
> are blasting it away right now ;)
>
> No, it doesn't work around bean archives, it works around alternatives,
> which we all know don't work too well from CDI 1.0.
>
> So far you aren't convincing me that bean archives are broken, but that that
>
>
> 1) we have a problem with global enablement of alternatives (which we know)
> 2) we have a problem with @Specializes and modularity (which we know)
>
> :-)
>
>>
>>
>>
>> But I think we'll finally come up with a solution if we take the time.
>>
>>
>> LieGrue,
>> strub
>>
>>
6:24 a.m.
On 15 Dec 2011, at 11:28, Mark Struberg wrote:
another point is that currently 1 BDA == 1 single jar file (or
WEB-INF/classes)
I don't believe this is specified at all? If so where, I think this is wrong, and not
the intent, and we just need to tweak the language a bit.
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(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)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.
>
5117
days inactive
5136
days old
18 comments
6 participants
participants (6)
-
Ales Justin -
Ales Justin -
Arne Limburg -
Fabien Marsaud -
Mark Struberg -
Pete Muir