<div dir="ltr">Guys,<div><br></div><div>As I said at the beginning, this thread is not about a pros and cons about this feature. Everybody's agree that we should find a solution for this ticket even if some of us (including me) start to find that the ratio value for users on time spend discussed this is becoming very low.</div><div><br></div><div>It was about adding the PR proposed by Mark in the spec.</div><div><br></div><div><div>If I count the binding vote we have the following result </div><div>-1: 4</div><div>+1: 9<br></div><div><br></div><div>So according to the vote I should merge the PR right away. As there were a lot of reserve in +1 vote I ask again to the -1 voters if they agree with the merging of PR 271 which was the initial question.</div></div><div><br></div><div>Antoine</div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Le lun. 15 févr. 2016 à 09:29, Martin Kouba <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Dne 13.2.2016 v 23:24 John D. Ament napsal(a):<br>
> Some comments in line.<br>
><br>
> On Sat, Feb 13, 2016 at 4:22 PM David Blevins <<a href="mailto:david.blevins@gmail.com" target="_blank">david.blevins@gmail.com</a><br>
> <mailto:<a href="mailto:david.blevins@gmail.com" target="_blank">david.blevins@gmail.com</a>>> wrote:<br>
><br>
> Read what I could get my hands on. Unfortunately the JIRA itself<br>
> has 36 comments which won’t load/expand in Safari or Chrome. But I<br>
> think I get the summary.<br>
><br>
><br>
> Sounds like a not too responsive UI. I wonder if Atlassian has a test<br>
> for 36 comments. XD<br>
><br>
><br>
> High level, I agree with both Mark and Martin.<br>
><br>
> - Agree with Mark: Where I see this feature being important is in<br>
> our EJB/CDI alignment efforts. This appears to be the rare case<br>
> where the CDI spec is more strict than the EJB spec and a speed bump<br>
> in someone’s efforts to port an EJB application to CDI. For that<br>
> reason, this to me upgrades from nice-to-have to we-must-find-a-way.<br>
><br>
><br>
> Yep, and in thinking about past jobs have run into the issue. People<br>
> don't read every line of a spec, and don't always understand why<br>
> something stopped working.<br>
><br>
><br>
> - Agree with Martin: I also strongly dislike the use of beans.xml<br>
> in any fashion and system properties even more. Aside from being<br>
> cumbersome for users, I’m particularly against setting a trend of<br>
> using system properties to bail us out of hard API design issues.<br>
> This concern trumps the above and I would -1 this vote as-is.<br>
><br>
><br>
> That said, I’m not sure if this approach is workable in any way, but<br>
> here goes:<br>
><br>
> We keep the default rule of beans with final methods being<br>
> unproxyable unless explicit action in code is taken and the class is:<br>
><br>
> - explicitly produced via @Produces<br>
> - added explicitly via an extension<br>
><br>
><br>
> I don't see a reason that the bean manager needs to ignore classes with<br>
> final methods. More-so, I don't see the strategy as being<br>
> comprehensible to the typical developer that they need a producer.<br>
> Sure, for 3PL's you're probably already creating a producer. For cases<br>
> where I just made my class with a final method, I shouldn't be penalized.<br>
><br>
> Less boilerplate, that's one of the goals right? If so, I don't see why<br>
> we can't just deal with a final method in a proxy - don't extend it.<br>
<br>
Do you mean to simply ignore the method? If we do (the current<br>
non-portable solution of OWB and Weld) a user might be suprised why a<br>
method invoked on a proxy does not reach the target instance (it will be<br>
invoked upon a client proxy instance). Miserable default behavior I<br>
believe. And this will happen for a client proxy for non-interface bean<br>
types.<br>
<br>
><br>
> The gotcha that I still see is around interceptor bindings. They need<br>
> to be explicitly disallowed on final methods, and big ole warning put in<br>
> when you have interceptors on classes with final methods.<br>
><br>
><br>
> Effectively the BeanManager would continue to ignore beans with<br>
> final methods as proxyable in a classpath scan, but the application<br>
> could “go back” and explicitly put them into the BeanManager as<br>
> proxyable.<br>
><br>
><br>
> Thoughts? Big holes in there?<br>
><br>
><br>
><br>
> -David<br>
><br>
><br>
>> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand<br>
>> <<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a> <mailto:<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>>> wrote:<br>
>><br>
>> Hi Guys,<br>
>><br>
>> Some EG members (like David Blevins) asked to have until the ned<br>
>> of the week-end to vote here.<br>
>> I find interesting to have the more possible input but as the<br>
>> rules were to end the vote tonight, I wanted to be sure that<br>
>> nobody has any objection for closing the vote on sunday 11:59pm CET.<br>
>><br>
>> Regards,<br>
>><br>
>> Antoine<br>
>><br>
>> Le ven. 12 févr. 2016 à 17:23, Mark Struberg <<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a><br>
>> <mailto:<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>>> a écrit :<br>
>><br>
>> Sure, that might probably be a viable way to do it.<br>
>><br>
>> Oki, here are the two use cases which we need to solve:<br>
>><br>
>> 1.)<br>
>> @Produces<br>
>> @ApplicationScoped<br>
>> public SomeWeirdThirdPartyClassWithFinalMethods createIt()<br>
>> {return …};<br>
>><br>
>> 2.)<br>
>> @ApplicationSCoped<br>
>> public class MySubclass extends<br>
>> SomeWeirdThirdPartyClassWithFinalMethods {}<br>
>><br>
>> Any other use case?<br>
>><br>
>> Can you please elaborate how your idea will look like? Just a<br>
>> few ideas so we can get it running.<br>
>><br>
>> txs and LieGrue,<br>
>> strub<br>
>><br>
>><br>
>> PS: Again: I’m NOT interested to get my approach in. All I’m<br>
>> interested in is a _solution_ for this real world problem. But<br>
>> there was simply no alternative proposed so far…<br>
>><br>
>><br>
>><br>
>> > Am 12.02.2016 um 17:12 schrieb Pete Muir <<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a><br>
>> <mailto:<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>>>:<br>
>> ><br>
>> > -1<br>
>> ><br>
>> > The problem seems real, but proposed approach doesn't sit<br>
>> right with<br>
>> > me. I think it would be better to follow the EJB approach,<br>
>> and add a<br>
>> > way to be able to declare a method as "not a business method" (a<br>
>> > business method is also a thing in CDI IIRC).<br>
>> ><br>
>> > For example, e.g. using beans.xml and an annotation. This<br>
>> then allows<br>
>> > the spec to consistently treat this public method as not a<br>
>> business<br>
>> > method.<br>
>> ><br>
>> > On 9 February 2016 at 16:36, Antoine Sabot-Durand<br>
>> > <<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a> <mailto:<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>>><br>
>> wrote:<br>
>> >> Hi all,<br>
>> >><br>
>> >> There have been a lot of discussion around CDI-527 in the<br>
>> last weeks:<br>
>> >> <a href="https://issues.jboss.org/browse/CDI-527" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-527</a><br>
>> >><br>
>> >> Mark proposed a PR:<br>
>> >> <a href="https://github.com/cdi-spec/cdi/pull/271" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/271</a><br>
>> >><br>
>> >> But we don't agree on adding this feature to the spec.<br>
>> >> This vote is to decide if we should add this feature at the<br>
>> spec level now,<br>
>> >> or not.<br>
>> >> Should we vote this feature down, that won't mean it will<br>
>> be completely<br>
>> >> dropped: it could be implemented as non portable feature in<br>
>> both Spec or<br>
>> >> even be included as experimental feature in the spec (in<br>
>> annexes) as<br>
>> >> describe in the PR comments<br>
>> >> Vote starts now, only vote from EG members are binding (but<br>
>> you can give<br>
>> >> your opinion if not part of the EG) and will last 72 hours.<br>
>> >><br>
>> >> You vote with the following values:<br>
>> >> +1 : I'm favorable for adding this feature in the spec<br>
>> >> -1 : I'm against adding this feature in the spec<br>
>> >> 0 : I don't care<br>
>> >><br>
>> >> Thank you for your attention and your vote.<br>
>> >><br>
>> >> Antoine Sabot-Durand<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> cdi-dev mailing list<br>
>> >> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<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" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> >><br>
>> >> Note that for all code provided on this list, the provider<br>
>> licenses the code<br>
>> >> under the Apache License, Version 2<br>
>> >> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all<br>
>> other ideas<br>
>> >> provided on this list, the provider waives all patent and<br>
>> other intellectual<br>
>> >> property rights inherent in such information.<br>
>> > _______________________________________________<br>
>> > cdi-dev mailing list<br>
>> > <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<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" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> ><br>
>> > Note that for all code provided on this list, the provider<br>
>> licenses the code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all<br>
>> other ideas provided on this list, the provider waives all<br>
>> patent and other intellectual property rights inherent in such<br>
>> information.<br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<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" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider<br>
>> licenses the code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
>> ideas provided on this list, the provider waives all patent and<br>
>> other intellectual property rights inherent in such information.<br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<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" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses<br>
> the code under the Apache License, Version 2<br>
> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
> ideas provided on this list, the provider waives all patent and<br>
> other intellectual property rights inherent in such information.<br>
><br>
><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" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
><br>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<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" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
</blockquote></div></div></div></div>