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