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