<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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 class=""><br class=""></div><div class="">High level, I agree with both Mark and Martin.</div><div class=""><br class=""></div><div class=""> - 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 class=""><br class=""></div><div class=""> - 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 class=""><br class=""></div><div class="">That said, I’m not sure if this approach is workable in any way, but here goes:</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""> - explicitly produced via @Produces</div><div class=""> - added explicitly via an extension</div><div class=""><br class=""></div><div class=""><div class="">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 class=""><br class=""></div><div class=""><div class=""><br class=""></div></div><div class="">Thoughts? Big holes in there?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-David</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net" class="">antoine@sabot-durand.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Guys, <div class=""><br class=""></div><div class="">Some EG members (like David Blevins) asked to have until the ned of the week-end to vote here.</div><div class="">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 class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">Antoine</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">Le ven. 12 févr. 2016 à 17:23, Mark Struberg <<a href="mailto:struberg@yahoo.de" class="">struberg@yahoo.de</a>> a écrit :<br class=""></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 class="">
<br class="">
Oki, here are the two use cases which we need to solve:<br class="">
<br class="">
1.)<br class="">
@Produces<br class="">
@ApplicationScoped<br class="">
public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return …};<br class="">
<br class="">
2.)<br class="">
@ApplicationSCoped<br class="">
public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {}<br class="">
<br class="">
Any other use case?<br class="">
<br class="">
Can you please elaborate how your idea will look like? Just a few ideas so we can get it running.<br class="">
<br class="">
txs and LieGrue,<br class="">
strub<br class="">
<br class="">
<br class="">
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 class="">
<br class="">
<br class="">
<br class="">
> Am 12.02.2016 um 17:12 schrieb Pete Muir <<a href="mailto:pmuir@redhat.com" target="_blank" class="">pmuir@redhat.com</a>>:<br class="">
><br class="">
> -1<br class="">
><br class="">
> The problem seems real, but proposed approach doesn't sit right with<br class="">
> me. I think it would be better to follow the EJB approach, and add a<br class="">
> way to be able to declare a method as "not a business method" (a<br class="">
> business method is also a thing in CDI IIRC).<br class="">
><br class="">
> For example, e.g. using beans.xml and an annotation. This then allows<br class="">
> the spec to consistently treat this public method as not a business<br class="">
> method.<br class="">
><br class="">
> On 9 February 2016 at 16:36, Antoine Sabot-Durand<br class="">
> <<a href="mailto:antoine@sabot-durand.net" target="_blank" class="">antoine@sabot-durand.net</a>> wrote:<br class="">
>> Hi all,<br class="">
>><br class="">
>> There have been a lot of discussion around CDI-527 in the last weeks:<br class="">
>> <a href="https://issues.jboss.org/browse/CDI-527" rel="noreferrer" target="_blank" class="">https://issues.jboss.org/browse/CDI-527</a><br class="">
>><br class="">
>> Mark proposed a PR:<br class="">
>> <a href="https://github.com/cdi-spec/cdi/pull/271" rel="noreferrer" target="_blank" class="">https://github.com/cdi-spec/cdi/pull/271</a><br class="">
>><br class="">
>> But we don't agree on adding this feature to the spec.<br class="">
>> This vote is to decide if we should add this feature at the spec level now,<br class="">
>> or not.<br class="">
>> Should we vote this feature down, that won't mean it will be completely<br class="">
>> dropped: it could be implemented as non portable feature in both Spec or<br class="">
>> even be included as experimental feature in the spec (in annexes) as<br class="">
>> describe in the PR comments<br class="">
>> Vote starts now, only vote from EG members are binding (but you can give<br class="">
>> your opinion if not part of the EG) and will last 72 hours.<br class="">
>><br class="">
>> You vote with the following values:<br class="">
>> +1 : I'm favorable for adding this feature in the spec<br class="">
>> -1 : I'm against adding this feature in the spec<br class="">
>> 0 : I don't care<br class="">
>><br class="">
>> Thank you for your attention and your vote.<br class="">
>><br class="">
>> Antoine Sabot-Durand<br class="">
>><br class="">
>> _______________________________________________<br class="">
>> cdi-dev mailing list<br class="">
>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" class="">cdi-dev@lists.jboss.org</a><br class="">
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br class="">
>><br class="">
>> Note that for all code provided on this list, the provider licenses the code<br class="">
>> under the Apache License, Version 2<br class="">
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank" class="">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br class="">
>> provided on this list, the provider waives all patent and other intellectual<br class="">
>> property rights inherent in such information.<br class="">
> _______________________________________________<br class="">
> cdi-dev mailing list<br class="">
> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" class="">cdi-dev@lists.jboss.org</a><br class="">
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br class="">
><br class="">
> 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" class="">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 class="">
<br class="">
</blockquote></div></div>
_______________________________________________<br class="">cdi-dev mailing list<br class=""><a href="mailto:cdi-dev@lists.jboss.org" class="">cdi-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/cdi-dev<br class=""><br class="">Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). 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 class=""></body></html>