Sorry for pitching in so late.
(been busy with hacking something similar for our Ceylon M1 :-)
Imho, I don't see how moving the visibility to either Context or Contextual will
help.
I'm more into Pete's favor (and w/o being bias), as there is no way on earth devs
will know how to properly implement this in Context or Contextual.
I've stated this a few times already, I actually like BDA.
It's probably just the lack of proper wording and listing *all* visibility rules
(which is definitely hard, but hey this is *the* spec) in the spec that lead to issues
that we see now.
You only get full visibility rules from CL hierarchy / wiring.
But as we all know the CL API doesn't expose anything about this hierarchy / wiring,
hence the only one that knows this is the container, which needs a mechanism to abstract
this - aka BDA.
This way you -- as it is now -- push the nitty-gritty CL details to container devs, not
the users.
And if you don't have exotic rules -- as we potentially had in MC -- implementing BDA
is not that difficult.
e.g. JEE is pretty straight forward, with only a few exceptions
Imo we just need to set better rules on alts, iceptors, decorators, specializes, etc.
Or even extend the config, so the user can be even more explicit; e.g. force certain
isolation, filtering, etc
-Ales
On Dec 15, 2011, at 9:35 PM, Arne Limburg wrote:
Ok, as Mark mentioned: Our real problem with class-visibility is:
What classloader will Contextual.create use to create the contextual. If we would know
this, we could implement container-checks for class-visibility.
So from this comes another idea: What about adding a method getContextualClassLoader() to
the Contextual interface? This method should return the classloader that will be used for
instance-creation. The container then could check class-visibility for specializing beans,
interceptors, decorators and so on.
Cheers,
Arne
-----Ursprüngliche Nachricht-----
Von: cdi-dev-bounces(a)lists.jboss.org [mailto:cdi-dev-bounces@lists.jboss.org] Im Auftrag
von Arne Limburg
Gesendet: Donnerstag, 15. Dezember 2011 14:16
An: Mark Struberg
Cc: cdi-dev
Betreff: Re: [cdi-dev] easy solution for class visibility checks?
OK, then the question is: How would you implement Context.isVisible? I'm pretty sure,
that if your solution works, there would be a very generic implementation for it, that we
could use to specify container-behavior. Sounds like it could work, but I still need to
think about it...
Cheers,
Arne
-----Ursprüngliche Nachricht-----
Von: Mark Struberg [mailto:struberg@yahoo.de]
Gesendet: Donnerstag, 15. Dezember 2011 14:04
An: Arne Limburg; Fabien Marsaud
Cc: cdi-dev; Pete Muir
Betreff: Re: AW: [cdi-dev] easy solution for class visibility checks?
Thought about that as well, but the problem is that the ClassLoader of a Context is most
times irrellevant.
E.g. for @RequestScoped, the RequestContext.class is still in weld.jar or owb-impl.jar
which is in turn part of the very outermost container classloader.
The RequestContext never uses the RequestContext.class.getClassLoader but is just a
Map<Bean<T>,T /*created via Bean<T>#create()*/>
Maybe I'm also a bit too fixated on the way this stuff works in OWB (where we
currently don't support EnterpriseApplicationScoped out of the box).
Because it's not only the Context, it's also the way how
Contextual<T>#create works. Which ClassLoader does it take?
*stillscratchingmyhead*
LieGrue,
strub
> ________________________________
> From: Arne Limburg <arne.limburg(a)openknowledge.de>
> To: Fabien Marsaud <fabmars(a)gmail.com>; Mark Struberg
> <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Sent: Thursday, December 15, 2011 1:29 PM
> Subject: AW: [cdi-dev] easy solution for class visibility checks?
>
>
> Hi,
>
> But Mark’s idea is good anyway. Couldn’t that check be made by the container? The
spec just would need to write down the visibility-rules.
> It seems to have to do something with the classloader of the Context and the
classloader of the bean type.
> Something like “A bean is visible to a context if the bean-class is the same
(meanding Object identity) as the class of the same name that is returned by the
classloader of the Context-Instance”
>
> Cheers,
> Arne
>
> Von:cdi-dev-bounces@lists.jboss.org
> [mailto:cdi-dev-bounces@lists.jboss.org] Im Auftrag von Fabien Marsaud
> Gesendet: Donnerstag, 15. Dezember 2011 13:20
> An: Mark Struberg
> Cc: cdi-dev
> Betreff: Re: [cdi-dev] easy solution for class visibility checks?
>
>> Yup, I also don't really like it to make the Contexts responsible alone,
because it might make it harder to implement portable Contexts.
>
> I was about to say the same. Usually a scope is straightforward:
> @Scope @Retention @Target public @interface MyScope {}
>
> But the context taking care of it has to drag the whole carriage: the beanstore, the
2 get() methods and the cleanup. This may be not tedious for you, but it definitely is for
the average programmer (if he dares ot make it right, threadsafe, etc).
>
> A visibility method would add more complications and give a serious opportunity to
the developper to wreck havoc. There should be at least a default impl and/or a higher
order instance taking care of the visibility things.
>
> fm.
> On Thu, Dec 15, 2011 at 12:28 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
> another point is that currently 1 BDA == 1 single jar file (or
> WEB-INF/classes)
>
>
> But that's just way too restrictive imo. IF, then it should treat all
jars/classes in the same webapp as 1 BDA and all shared EAR jars as another BDA.
> But still then, there is a lot left undefined. Imo all the BDA stuff is not worth the
pita.
>
>
>> Good point. There is definitely a shared responsibility though here,
>> and I'm not sure we can shift all responsibility to the context.
> Yup, I also don't really like it to make the Contexts responsible alone, because
it might make it harder to implement portable Contexts.
> Otoh it's pretty pragmatic and is doable in all situations I knew.
>
> Maybe we can collect samples (use-cases) and play with them?
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Pete Muir <pmuir(a)redhat.com>
>> To: Mark Struberg <struberg(a)yahoo.de>
>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
>> Sent: Thursday, December 15, 2011 12:14 PM
>> Subject: Re: [cdi-dev] easy solution for class visibility checks?
>>
>>
>> On 15 Dec 2011, at 11:10, Mark Struberg wrote:
>>
>>> The BDA stuff is not only broken for @Alternatives, but also for
>> <interceptors> and <decorators>
>>
>> Right, I wrote e.g. not i.e. ;-) Sorry, was just being lazy.
>>
>>>
>>> Plus: @Specializes is NOT affected by BDA as per CDI-1.0. But still
>>> gets
>> hit by class visibility issues.
>>
>> Right, this is not right in the CDI spec.
>>
>>>
>>>
>>> Imo the container just cannot know whether a 3rd party Context is
>>> going to
>> use the ThreadContextClassLoader, the SystemClassloader, the
>> MyScoped.class.getClassLoader() etc. There is nothing a container can
>> do about it, because _only_ the Context knows where it will store it's
stuff.
>>
>> Good point. There is definitely a shared responsibility though here,
>> and I'm not sure we can shift all responsibility to the context.
>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
> --
>
http://www.suntriprecords.com
>
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev