>Yup, I also don't really like it to make the Contexts responsible alone,
because it might make it harder to implement portable Contexts.<br>
<br>I was about to say the same. Usually a scope is straightforward:<br>@Scope @Retention @Target public @interface MyScope {}<br><br>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).<br>
<br>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.<br>
<br>fm.<br><br><div class="gmail_quote">On Thu, Dec 15, 2011 at 12:28 PM, Mark Struberg <span dir="ltr"><<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
another point is that currently 1 BDA == 1 single jar file (or WEB-INF/classes)<br>
<br>
<br>
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.<br>
But still then, there is a lot left undefined. Imo all the BDA stuff is not worth the pita.<br>
<div><br>
<br>
> Good point. There is definitely a shared responsibility though here, and I'm<br>
> not sure we can shift all responsibility to the context.<br>
<br>
</div>Yup, I also don't really like it to make the Contexts responsible alone, because it might make it harder to implement portable Contexts.<br>
Otoh it's pretty pragmatic and is doable in all situations I knew.<br>
<br>
Maybe we can collect samples (use-cases) and play with them?<br>
<div><br>
LieGrue,<br>
strub<br>
<br>
<br>
<br>
----- Original Message -----<br>
> From: Pete Muir <<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>><br>
> To: Mark Struberg <<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>><br>
> Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
</div><div>> Sent: Thursday, December 15, 2011 12:14 PM<br>
> Subject: Re: [cdi-dev] easy solution for class visibility checks?<br>
><br>
><br>
</div><div><div>> On 15 Dec 2011, at 11:10, Mark Struberg wrote:<br>
><br>
>> The BDA stuff is not only broken for @Alternatives, but also for<br>
> <interceptors> and <decorators><br>
><br>
> Right, I wrote e.g. not i.e. ;-) Sorry, was just being lazy.<br>
><br>
>><br>
>> Plus: @Specializes is NOT affected by BDA as per CDI-1.0. But still gets<br>
> hit by class visibility issues.<br>
><br>
> Right, this is not right in the CDI spec.<br>
><br>
>><br>
>><br>
>> Imo the container just cannot know whether a 3rd party Context is going to<br>
> use the ThreadContextClassLoader, the SystemClassloader, the<br>
> MyScoped.class.getClassLoader() etc. There is nothing a container can do about<br>
> it, because _only_ the Context knows where it will store it's stuff.<br>
><br>
> Good point. There is definitely a shared responsibility though here, and I'm<br>
> not sure we can shift all responsibility to the context.<br>
><br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><a href="http://www.suntriprecords.com" target="_blank">http://www.suntriprecords.com</a><br><br>