<div dir="ltr">Hi all,<div><br></div><div>Apparently, the preferred solution for CDI-527 is the first Mark proposed: a dedicated annotation.</div><div>Since we are introducing an annotation dedicated to proxy perhaps we should think it in a more general proxy configuration way to be used for other tickets like CDI-414 [1]</div><div><br></div><div>That would give something like:</div><div>@ProxyConfig(force=true) to force proxy even if the class has final method</div><div>and</div><div> <span style="line-height:1.5">@ProxyConfig(force=false, self=true) to have internal code in the bean to be intercepted / deocrated</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">wdyt</span></div><div><br></div><div>[1] <a href="https://issues.jboss.org/browse/CDI-414">https://issues.jboss.org/browse/CDI-414</a></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Le mar. 16 févr. 2016 à 17:56, Mark Struberg &lt;<a href="mailto:struberg@yahoo.de">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">&gt;    - explicitly produced via @Produces<br>
There are other use cases beside produces<br>
e.g. @ApplicationScoped class MyClass extends ClassWithFinalMethods<br>
<br>
But if we add this as well, then there is no other use case left!<br>
You could also go on and remove the whole rule in that case.<br>
But that is exactly what we don’t like, right?<br>
Because Random Joe would fall into this trap way too easily.<br>
<br>
&gt;    - added explicitly via an extension<br>
<br>
Pretty hard for an average user to do.<br>
And would also trump backward compatibility.<br>
<br>
LieGrue,<br>
strub<br>
<br>
<br>
<br>
&gt; Am 13.02.2016 um 22:21 schrieb David Blevins &lt;<a href="mailto:david.blevins@gmail.com" target="_blank">david.blevins@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt; High level, I agree with both Mark and Martin.<br>
&gt;<br>
&gt;  - 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.<br>
&gt;<br>
&gt;  - 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.<br>
&gt;<br>
&gt; That said, I’m not sure if this approach is workable in any way, but here goes:<br>
&gt;<br>
&gt; We keep the default rule of beans with final methods being unproxyable unless explicit action in code is taken and the class is:<br>
&gt;<br>
&gt;    - explicitly produced via @Produces<br>
&gt;    - added explicitly via an extension<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt;<br>
&gt; Thoughts?  Big holes in there?<br>
&gt;<br>
&gt;<br>
&gt; -David<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.</blockquote></div>