easy solution for class visibility checks?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

easy solution for class visibility checks?

Mark Struberg


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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Pete Muir
Administrator
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

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

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


Imo the container just cannot know whether a 3rd party Context is going to use the ThreadContextClassLoader, the SystemClassloader, the MyScoped.class.getClassLoader() etc. There is nothing a container can do about it, because _only_ the Context knows where it will store it's stuff.


LieGrue,
strub




----- Original Message -----

> From: Pete Muir <[hidden email]>
> To: Mark Struberg <[hidden email]>
> Cc: cdi-dev <[hidden email]>
> 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
>>  [hidden email]
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Pete Muir
Administrator

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Mark Struberg
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 <[hidden email]>
> To: Mark Struberg <[hidden email]>
> Cc: cdi-dev <[hidden email]>
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Fabien Marsaud
>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 <[hidden email]> 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 <[hidden email]>
> To: Mark Struberg <[hidden email]>
> Cc: cdi-dev <[hidden email]>
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
http://www.suntriprecords.com


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Pete Muir
Administrator
In reply to this post by Mark Struberg

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 <[hidden email]>
>> To: Mark Struberg <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Arne Limburg
In reply to this post by Fabien Marsaud

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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]>
> To: Mark Struberg <[hidden email]>
> Cc: cdi-dev <[hidden email]>

> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev




--
http://www.suntriprecords.com


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Mark Struberg
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 <[hidden email]>
>To: Fabien Marsaud <[hidden email]>; Mark Struberg <[hidden email]>
>Cc: cdi-dev <[hidden email]>
>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:[hidden email] [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]>
>> To: Mark Struberg <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> 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
>[hidden email]
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
>--
>http://www.suntriprecords.com
>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Arne Limburg
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:[hidden email]]
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 <[hidden email]>
>To: Fabien Marsaud <[hidden email]>; Mark Struberg
><[hidden email]>
>Cc: cdi-dev <[hidden email]>
>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:[hidden email]
>[mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]>
>> To: Mark Struberg <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> 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
>[hidden email]
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
>--
>http://www.suntriprecords.com
>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Arne Limburg
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: [hidden email] [mailto:[hidden email]] 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:[hidden email]]
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 <[hidden email]>
>To: Fabien Marsaud <[hidden email]>; Mark Struberg
><[hidden email]>
>Cc: cdi-dev <[hidden email]>
>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:[hidden email]
>[mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]>
>> To: Mark Struberg <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> 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
>[hidden email]
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
>--
>http://www.suntriprecords.com
>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Ales Justin-2
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: [hidden email] [mailto:[hidden email]] 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:[hidden email]]
> 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 <[hidden email]>
>> To: Fabien Marsaud <[hidden email]>; Mark Struberg
>> <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> 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:[hidden email]
>> [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]>
>>> To: Mark Struberg <[hidden email]>
>>> Cc: cdi-dev <[hidden email]>
>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>>
>> --
>> http://www.suntriprecords.com
>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Ales Justin
In reply to this post by Arne Limburg
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: [hidden email] [mailto:[hidden email]] 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:[hidden email]]
> 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 <[hidden email]>
>> To: Fabien Marsaud <[hidden email]>; Mark Struberg
>> <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> 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:[hidden email]
>> [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]>
>>> To: Mark Struberg <[hidden email]>
>>> Cc: cdi-dev <[hidden email]>
>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>>
>> --
>> http://www.suntriprecords.com
>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Mark Struberg
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 <[hidden email]>
> To: cdi-dev <[hidden email]>
> 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: [hidden email]
> [mailto:[hidden email]] 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:[hidden email]]
>>  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 <[hidden email]>
>>>  To: Fabien Marsaud <[hidden email]>; Mark Struberg
>>>  <[hidden email]>
>>>  Cc: cdi-dev <[hidden email]>
>>>  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:[hidden email]
>>>  [mailto:[hidden email]] 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
> <[hidden email]> 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 <[hidden email]>
>>>>  To: Mark Struberg <[hidden email]>
>>>>  Cc: cdi-dev <[hidden email]>
>>>>  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
>>>  [hidden email]
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>
>>>
>>>  --
>>>  http://www.suntriprecords.com
>>>
>>>
>>
>>  _______________________________________________
>>  cdi-dev mailing list
>>  [hidden email]
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>  _______________________________________________
>>  cdi-dev mailing list
>>  [hidden email]
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Ales Justin
> 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


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Pete Muir
Administrator
In reply to this post by Mark Struberg

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 <[hidden email]>
>> To: cdi-dev <[hidden email]>
>> 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: [hidden email]
>> [mailto:[hidden email]] 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:[hidden email]]
>>> 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 <[hidden email]>
>>>> To: Fabien Marsaud <[hidden email]>; Mark Struberg
>>>> <[hidden email]>
>>>> Cc: cdi-dev <[hidden email]>
>>>> 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:[hidden email]
>>>> [mailto:[hidden email]] 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
>> <[hidden email]> 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 <[hidden email]>
>>>>> To: Mark Struberg <[hidden email]>
>>>>> Cc: cdi-dev <[hidden email]>
>>>>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.suntriprecords.com
>>>>
>>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Mark Struberg


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 <[hidden email]>
> To: Mark Struberg <[hidden email]>
> Cc: Ales Justin <[hidden email]>; cdi-dev <[hidden email]>
> 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
>>
>> 

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Pete Muir
Administrator
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 <[hidden email]>
>> To: Mark Struberg <[hidden email]>
>> Cc: Ales Justin <[hidden email]>; cdi-dev <[hidden email]>
>> 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
>>>
>>>  


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: easy solution for class visibility checks?

Ales Justin
In reply to this post by Ales Justin-2
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: [hidden email] [mailto:[hidden email]] 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:[hidden email]]
>> 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 <[hidden email]>
>>> To: Fabien Marsaud <[hidden email]>; Mark Struberg
>>> <[hidden email]>
>>> Cc: cdi-dev <[hidden email]>
>>> 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:[hidden email]
>>> [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]>
>>>> To: Mark Struberg <[hidden email]>
>>>> Cc: cdi-dev <[hidden email]>
>>>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>
>>>
>>> --
>>> http://www.suntriprecords.com
>>>
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev