<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 <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> - 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>
> - 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>
> Am 13.02.2016 um 22:21 schrieb David Blevins <<a href="mailto:david.blevins@gmail.com" target="_blank">david.blevins@gmail.com</a>>:<br>
><br>
> 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>
><br>
> High level, I agree with both Mark and Martin.<br>
><br>
> - 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>
><br>
> - 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>
><br>
> That said, I’m not sure if this approach is workable in any way, but here goes:<br>
><br>
> We keep the default rule of beans with final methods being 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>
> 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>
><br>
><br>
> Thoughts? Big holes in there?<br>
><br>
><br>
> -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>