Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand

Am 09.02.2016 um 17:36 schrieb Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

-1 My explanation: https://github.com/cdi-spec/cdi/pull/271#issuecomment-179105513 We're going to release Weld 2.3.3.Final later this week. So both impls provide a non-portable solution already. However, if the EG decides to go this way I'm strongly in favor of: * unifying CDI configuration (something similar to Weld and OWB configurations) * NOT reusing beans.xml * NOT to take into account the environment variables Martin Dne 9.2.2016 v 17:36 Antoine Sabot-Durand napsal(a): > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

Dne 10.2.2016 v 13:48 John D. Ament napsal(a): > +1 for adding this feature to the spec. > > -1 for adding it the way it is written currently. This isn't to say > that Mark's idea is bad, its just that it puts too much onus on the > application developer to know the structure of its classes, both > internally developed and externally provided. > > We should follow a pattern closer to EJB (in my opinion) where the > non-proxyable methods are just not proxied - you won't get transactions, > etc available. -1 I think you cannot declare a final method on a NIV session bean (you get validation error) and it's easy to create a proxy for local/remote interface - no such methods. I also think we cannot implement this in Weld as we're using subclassing for client proxies. If you don't override (i.e. if you ignore) such a method than it will not be invoked upon the contextual instance but upon the clien proxy instance (subclass). > > John > > On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand > <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote: > > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec > level now, or not. > Should we vote this feature down, that won't mean it will be > completely dropped: it could be implemented as non portable feature > in both Spec or even be included as experimental feature in the spec > (in annexes) as describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can > give your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic

Am 10.02.2016 um 14:12 schrieb John D. Ament <john.d.ament(a)gmail.com&gt;: Not sure if we want to pollute the vote thread, so changing titles. I think to summarize my feelings, think about the relationship between interface Foo and implementation FooImpl. Foo is defined: interface Foo { String doWork(); } FooImpl is defined as: public class FooImpl implements Foo { public String doWork() { return "i'm done"; } public final String doSomethingElse() { return "something else"; } } The way CDI impls work right now, the proxy is created for the impl. The way EJBs proxy right now, they proxy the interface. If CDI proxied both the interface and impl separately, and substituted based on the injection point, this would work. On Wed, Feb 10, 2016 at 8:07 AM Martin Kouba <mkouba(a)redhat.com&gt; wrote: Dne 10.2.2016 v 13:48 John D. Ament napsal(a): > +1 for adding this feature to the spec. > > -1 for adding it the way it is written currently. This isn't to say > that Mark's idea is bad, its just that it puts too much onus on the > application developer to know the structure of its classes, both > internally developed and externally provided. > > We should follow a pattern closer to EJB (in my opinion) where the > non-proxyable methods are just not proxied - you won't get transactions, > etc available. -1 I think you cannot declare a final method on a NIV session bean (you get validation error) and it's easy to create a proxy for local/remote interface - no such methods. I also think we cannot implement this in Weld as we're using subclassing for client proxies. If you don't override (i.e. if you ignore) such a method than it will not be invoked upon the contextual instance but upon the clien proxy instance (subclass). > > John > > On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand > <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote: > > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec > level now, or not. > Should we vote this feature down, that won't mean it will be > completely dropped: it could be implemented as non portable feature > in both Spec or even be included as experimental feature in the spec > (in annexes) as describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can > give your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

We should follow a pattern closer to EJB (in my opinion) where the non-proxyable methods are just not proxied - you won’t get transactions, etc available.

Am 10.02.2016 um 13:48 schrieb John D. Ament <john.d.ament(a)gmail.com&gt;: +1 for adding this feature to the spec. -1 for adding it the way it is written currently. This isn't to say that Mark's idea is bad, its just that it puts too much onus on the application developer to know the structure of its classes, both internally developed and externally provided. We should follow a pattern closer to EJB (in my opinion) where the non-proxyable methods are just not proxied - you won't get transactions, etc available. John On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

Hi all, There have been a lot of discussion around CDI-527 in the last weeks: https://issues.jboss.org/browse/CDI-527 Mark proposed a PR: https://github.com/cdi-spec/cdi/pull/271 But we don't agree on adding this feature to the spec. This vote is to decide if we should add this feature at the spec level now, or not. Should we vote this feature down, that won't mean it will be completely dropped: it could be implemented as non portable feature in both Spec or even be included as experimental feature in the spec (in annexes) as describe in the PR comments Vote starts now, only vote from EG members are binding (but you can give your opinion if not part of the EG) and will last 72 hours. You vote with the following values: +1 : I'm favorable for adding this feature in the spec -1 : I'm against adding this feature in the spec 0 : I don't care Thank you for your attention and your vote. Antoine Sabot-Durand _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

Sure, that might probably be a viable way to do it. Oki, here are the two use cases which we need to solve: 1.) @Produces @ApplicationScoped public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return …}; 2.) @ApplicationSCoped public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {} Any other use case? Can you please elaborate how your idea will look like? Just a few ideas so we can get it running. txs and LieGrue, strub 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… > Am 12.02.2016 um 17:12 schrieb Pete Muir <pmuir(a)redhat.com&gt;: > > -1 > > The problem seems real, but proposed approach doesn't sit right with > me. I think it would be better to follow the EJB approach, and add a > way to be able to declare a method as "not a business method" (a > business method is also a thing in CDI IIRC). > > For example, e.g. using beans.xml and an annotation. This then allows > the spec to consistently treat this public method as not a business > method. > > On 9 February 2016 at 16:36, Antoine Sabot-Durand > <antoine(a)sabot-durand.net&gt; wrote: >> Hi all, >> >> There have been a lot of discussion around CDI-527 in the last weeks: >> https://issues.jboss.org/browse/CDI-527 >> >> Mark proposed a PR: >> https://github.com/cdi-spec/cdi/pull/271 >> >> But we don't agree on adding this feature to the spec. >> This vote is to decide if we should add this feature at the spec level now, >> or not. >> Should we vote this feature down, that won't mean it will be completely >> dropped: it could be implemented as non portable feature in both Spec or >> even be included as experimental feature in the spec (in annexes) as >> describe in the PR comments >> Vote starts now, only vote from EG members are binding (but you can give >> your opinion if not part of the EG) and will last 72 hours. >> >> You vote with the following values: >> +1 : I'm favorable for adding this feature in the spec >> -1 : I'm against adding this feature in the spec >> 0 : I don't care >> >> Thank you for your attention and your vote. >> >> Antoine Sabot-Durand >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> 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. > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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.

On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: Hi Guys, Some EG members (like David Blevins) asked to have until the ned of the week-end to vote here. 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. Regards, Antoine Le ven. 12 févr. 2016 à 17:23, Mark Struberg <struberg(a)yahoo.de <mailto:struberg@yahoo.de>> a écrit : Sure, that might probably be a viable way to do it. Oki, here are the two use cases which we need to solve: 1.) @Produces @ApplicationScoped public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return …}; 2.) @ApplicationSCoped public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {} Any other use case? Can you please elaborate how your idea will look like? Just a few ideas so we can get it running. txs and LieGrue, strub 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… > Am 12.02.2016 um 17:12 schrieb Pete Muir <pmuir(a)redhat.com <mailto:pmuir@redhat.com>>: > > -1 > > The problem seems real, but proposed approach doesn't sit right with > me. I think it would be better to follow the EJB approach, and add a > way to be able to declare a method as "not a business method" (a > business method is also a thing in CDI IIRC). > > For example, e.g. using beans.xml and an annotation. This then allows > the spec to consistently treat this public method as not a business > method. > > On 9 February 2016 at 16:36, Antoine Sabot-Durand > <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote: >> Hi all, >> >> There have been a lot of discussion around CDI-527 in the last weeks: >> https://issues.jboss.org/browse/CDI-527 <https://issues.jboss.org/browse/CDI-527> >> >> Mark proposed a PR: >> https://github.com/cdi-spec/cdi/pull/271 <https://github.com/cdi-spec/cdi/pull/271> >> >> But we don't agree on adding this feature to the spec. >> This vote is to decide if we should add this feature at the spec level now, >> or not. >> Should we vote this feature down, that won't mean it will be completely >> dropped: it could be implemented as non portable feature in both Spec or >> even be included as experimental feature in the spec (in annexes) as >> describe in the PR comments >> Vote starts now, only vote from EG members are binding (but you can give >> your opinion if not part of the EG) and will last 72 hours. >> >> You vote with the following values: >> +1 : I'm favorable for adding this feature in the spec >> -1 : I'm against adding this feature in the spec >> 0 : I don't care >> >> Thank you for your attention and your vote. >> >> Antoine Sabot-Durand >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/cdi-dev <https://lists.jboss.org/mailman/listinfo/cdi-dev> >> >> 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 <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. > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev <https://lists.jboss.org/mailman/listinfo/cdi-dev> > > 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 <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. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

Some comments in line. On Sat, Feb 13, 2016 at 4:22 PM David Blevins <david.blevins(a)gmail.com&gt; wrote: > 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. > Sounds like a not too responsive UI. I wonder if Atlassian has a test for 36 comments. XD > > High level, I agree with both Mark and Martin. > > - 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. > Yep, and in thinking about past jobs have run into the issue. People don't read every line of a spec, and don't always understand why something stopped working. > > - 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. > > That said, I’m not sure if this approach is workable in any way, but here > goes: > > We keep the default rule of beans with final methods being unproxyable > unless explicit action in code is taken and the class is: > > - explicitly produced via @Produces > - added explicitly via an extension > I don't see a reason that the bean manager needs to ignore classes with final methods. More-so, I don't see the strategy as being comprehensible to the typical developer that they need a producer. Sure, for 3PL's you're probably already creating a producer. For cases where I just made my class with a final method, I shouldn't be penalized. Less boilerplate, that's one of the goals right? If so, I don't see why we can't just deal with a final method in a proxy - don't extend it. 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. > > 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. > > > Thoughts? Big holes in there? > > > -David > > > On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand < > antoine(a)sabot-durand.net&gt; wrote: > > Hi Guys, > > Some EG members (like David Blevins) asked to have until the ned of the > week-end to vote here. > 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. > > Regards, > > Antoine > > Le ven. 12 févr. 2016 à 17:23, Mark Struberg <struberg(a)yahoo.de&gt; a > écrit : > >> Sure, that might probably be a viable way to do it. >> >> Oki, here are the two use cases which we need to solve: >> >> 1.) >> @Produces >> @ApplicationScoped >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return …}; >> >> 2.) >> @ApplicationSCoped >> public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods >> {} >> >> Any other use case? >> >> Can you please elaborate how your idea will look like? Just a few ideas >> so we can get it running. >> >> txs and LieGrue, >> strub >> >> >> 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… >> >> >> >> > Am 12.02.2016 um 17:12 schrieb Pete Muir <pmuir(a)redhat.com&gt;: >> > >> > -1 >> > >> > The problem seems real, but proposed approach doesn't sit right with >> > me. I think it would be better to follow the EJB approach, and add a >> > way to be able to declare a method as "not a business method" (a >> > business method is also a thing in CDI IIRC). >> > >> > For example, e.g. using beans.xml and an annotation. This then allows >> > the spec to consistently treat this public method as not a business >> > method. >> > >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand >> > <antoine(a)sabot-durand.net&gt; wrote: >> >> Hi all, >> >> >> >> There have been a lot of discussion around CDI-527 in the last weeks: >> >> https://issues.jboss.org/browse/CDI-527 >> >> >> >> Mark proposed a PR: >> >> https://github.com/cdi-spec/cdi/pull/271 >> >> >> >> But we don't agree on adding this feature to the spec. >> >> This vote is to decide if we should add this feature at the spec >> level now, >> >> or not. >> >> Should we vote this feature down, that won't mean it will be >> completely >> >> dropped: it could be implemented as non portable feature in both Spec >> or >> >> even be included as experimental feature in the spec (in annexes) as >> >> describe in the PR comments >> >> Vote starts now, only vote from EG members are binding (but you can >> give >> >> your opinion if not part of the EG) and will last 72 hours. >> >> >> >> You vote with the following values: >> >> +1 : I'm favorable for adding this feature in the spec >> >> -1 : I'm against adding this feature in the spec >> >> 0 : I don't care >> >> >> >> Thank you for your attention and your vote. >> >> >> >> Antoine Sabot-Durand >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> 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. >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > 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. >> >> _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

> Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com : > You can also extend 3rd party classes - no producer but same constraint

I also think it should be an option which is not only required for

@David: that comes pretty close to my original proposal to have a @AllowProxying

We probably would also need to extend the SPI in that case to allow

One more thing: This also hits already existing apps which move from Java6 to 7/8. I’m

@John > The gotcha that I still see is around interceptor bindings. They need

That could be a good thing to do. Of course it only is possible if the

> Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com : > You can also extend 3rd party classes - no producer but same constraint

> Read what I could get my hands on. Unfortunately the JIRA itself has

>> I find interesting to have the more possible input but as the rules

>> >> or not. >> >> Should we vote this feature down, that won't mean it will be

>> >> dropped: it could be implemented as non portable feature in both

>> >> even be included as experimental feature in the spec (in annexes) as >> >> describe in the PR comments >> >> Vote starts now, only vote from EG members are binding (but you can

>> >> under the Apache License, Version 2 >> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other

>> >> provided on this list, the provider waives all patent and other

Some comments in line. On Sat, Feb 13, 2016 at 4:22 PM David Blevins <david.blevins(a)gmail.com <mailto:david.blevins@gmail.com>> wrote: 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. Sounds like a not too responsive UI. I wonder if Atlassian has a test for 36 comments. XD High level, I agree with both Mark and Martin. - 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. Yep, and in thinking about past jobs have run into the issue. People don't read every line of a spec, and don't always understand why something stopped working. - 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. That said, I’m not sure if this approach is workable in any way, but here goes: We keep the default rule of beans with final methods being unproxyable unless explicit action in code is taken and the class is: - explicitly produced via @Produces - added explicitly via an extension I don't see a reason that the bean manager needs to ignore classes with final methods. More-so, I don't see the strategy as being comprehensible to the typical developer that they need a producer. Sure, for 3PL's you're probably already creating a producer. For cases where I just made my class with a final method, I shouldn't be penalized. Less boilerplate, that's one of the goals right? If so, I don't see why we can't just deal with a final method in a proxy - don't extend it.

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. 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. Thoughts? Big holes in there? -David > On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand > <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote: > > Hi Guys, > > Some EG members (like David Blevins) asked to have until the ned > of the week-end to vote here. > 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. > > Regards, > > Antoine > > Le ven. 12 févr. 2016 à 17:23, Mark Struberg <struberg(a)yahoo.de > <mailto:struberg@yahoo.de>> a écrit : > > Sure, that might probably be a viable way to do it. > > Oki, here are the two use cases which we need to solve: > > 1.) > @Produces > @ApplicationScoped > public SomeWeirdThirdPartyClassWithFinalMethods createIt() > {return …}; > > 2.) > @ApplicationSCoped > public class MySubclass extends > SomeWeirdThirdPartyClassWithFinalMethods {} > > Any other use case? > > Can you please elaborate how your idea will look like? Just a > few ideas so we can get it running. > > txs and LieGrue, > strub > > > 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… > > > > > Am 12.02.2016 um 17:12 schrieb Pete Muir <pmuir(a)redhat.com > <mailto:pmuir@redhat.com>>: > > > > -1 > > > > The problem seems real, but proposed approach doesn't sit > right with > > me. I think it would be better to follow the EJB approach, > and add a > > way to be able to declare a method as "not a business method" (a > > business method is also a thing in CDI IIRC). > > > > For example, e.g. using beans.xml and an annotation. This > then allows > > the spec to consistently treat this public method as not a > business > > method. > > > > On 9 February 2016 at 16:36, Antoine Sabot-Durand > > <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> > wrote: > >> Hi all, > >> > >> There have been a lot of discussion around CDI-527 in the > last weeks: > >> https://issues.jboss.org/browse/CDI-527 > >> > >> Mark proposed a PR: > >> https://github.com/cdi-spec/cdi/pull/271 > >> > >> But we don't agree on adding this feature to the spec. > >> This vote is to decide if we should add this feature at the > spec level now, > >> or not. > >> Should we vote this feature down, that won't mean it will > be completely > >> dropped: it could be implemented as non portable feature in > both Spec or > >> even be included as experimental feature in the spec (in > annexes) as > >> describe in the PR comments > >> Vote starts now, only vote from EG members are binding (but > you can give > >> your opinion if not part of the EG) and will last 72 hours. > >> > >> You vote with the following values: > >> +1 : I'm favorable for adding this feature in the spec > >> -1 : I'm against adding this feature in the spec > >> 0 : I don't care > >> > >> Thank you for your attention and your vote. > >> > >> Antoine Sabot-Durand > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> 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. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > 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. > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/cdi-dev 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. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

Guys, 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. It was about adding the PR proposed by Mark in the spec. If I count the binding vote we have the following result -1: 4 +1: 9 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. Antoine Le lun. 15 févr. 2016 à 09:29, Martin Kouba <mkouba(a)redhat.com&gt; a écrit : > > Dne 13.2.2016 v 23:24 John D. Ament napsal(a): > > Some comments in line. > > > > On Sat, Feb 13, 2016 at 4:22 PM David Blevins <david.blevins(a)gmail.com > > <mailto:david.blevins@gmail.com>> wrote: > > > > 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. > > > > > > Sounds like a not too responsive UI. I wonder if Atlassian has a test > > for 36 comments. XD > > > > > > High level, I agree with both Mark and Martin. > > > > - 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. > > > > > > Yep, and in thinking about past jobs have run into the issue. People > > don't read every line of a spec, and don't always understand why > > something stopped working. > > > > > > - 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. > > > > > > That said, I’m not sure if this approach is workable in any way, but > > here goes: > > > > We keep the default rule of beans with final methods being > > unproxyable unless explicit action in code is taken and the class > is: > > > > - explicitly produced via @Produces > > - added explicitly via an extension > > > > > > I don't see a reason that the bean manager needs to ignore classes with > > final methods. More-so, I don't see the strategy as being > > comprehensible to the typical developer that they need a producer. > > Sure, for 3PL's you're probably already creating a producer. For cases > > where I just made my class with a final method, I shouldn't be > penalized. > > > > Less boilerplate, that's one of the goals right? If so, I don't see why > > we can't just deal with a final method in a proxy - don't extend it. > > Do you mean to simply ignore the method? If we do (the current > non-portable solution of OWB and Weld) a user might be suprised why a > method invoked on a proxy does not reach the target instance (it will be > invoked upon a client proxy instance). Miserable default behavior I > believe. And this will happen for a client proxy for non-interface bean > types. > > > > > 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. > > > > > > 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. > > > > > > Thoughts? Big holes in there? > > > > > > > > -David > > > > > >> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand > >> <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> > wrote: > >> > >> Hi Guys, > >> > >> Some EG members (like David Blevins) asked to have until the ned > >> of the week-end to vote here. > >> 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. > >> > >> Regards, > >> > >> Antoine > >> > >> Le ven. 12 févr. 2016 à 17:23, Mark Struberg <struberg(a)yahoo.de > >> <mailto:struberg@yahoo.de>> a écrit : > >> > >> Sure, that might probably be a viable way to do it. > >> > >> Oki, here are the two use cases which we need to solve: > >> > >> 1.) > >> @Produces > >> @ApplicationScoped > >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() > >> {return …}; > >> > >> 2.) > >> @ApplicationSCoped > >> public class MySubclass extends > >> SomeWeirdThirdPartyClassWithFinalMethods {} > >> > >> Any other use case? > >> > >> Can you please elaborate how your idea will look like? Just a > >> few ideas so we can get it running. > >> > >> txs and LieGrue, > >> strub > >> > >> > >> 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… > >> > >> > >> > >> > Am 12.02.2016 um 17:12 schrieb Pete Muir <pmuir(a)redhat.com > >> <mailto:pmuir@redhat.com>>: > >> > > >> > -1 > >> > > >> > The problem seems real, but proposed approach doesn't sit > >> right with > >> > me. I think it would be better to follow the EJB approach, > >> and add a > >> > way to be able to declare a method as "not a business > method" (a > >> > business method is also a thing in CDI IIRC). > >> > > >> > For example, e.g. using beans.xml and an annotation. This > >> then allows > >> > the spec to consistently treat this public method as not a > >> business > >> > method. > >> > > >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand > >> > <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> > >> wrote: > >> >> Hi all, > >> >> > >> >> There have been a lot of discussion around CDI-527 in the > >> last weeks: > >> >> https://issues.jboss.org/browse/CDI-527 > >> >> > >> >> Mark proposed a PR: > >> >> https://github.com/cdi-spec/cdi/pull/271 > >> >> > >> >> But we don't agree on adding this feature to the spec. > >> >> This vote is to decide if we should add this feature at the > >> spec level now, > >> >> or not. > >> >> Should we vote this feature down, that won't mean it will > >> be completely > >> >> dropped: it could be implemented as non portable feature in > >> both Spec or > >> >> even be included as experimental feature in the spec (in > >> annexes) as > >> >> describe in the PR comments > >> >> Vote starts now, only vote from EG members are binding (but > >> you can give > >> >> your opinion if not part of the EG) and will last 72 hours. > >> >> > >> >> You vote with the following values: > >> >> +1 : I'm favorable for adding this feature in the spec > >> >> -1 : I'm against adding this feature in the spec > >> >> 0 : I don't care > >> >> > >> >> Thank you for your attention and your vote. > >> >> > >> >> Antoine Sabot-Durand > >> >> > >> >> _______________________________________________ > >> >> cdi-dev mailing list > >> >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >> > >> >> 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. > >> > _______________________________________________ > >> > cdi-dev mailing list > >> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > >> > https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > > >> > 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. > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> 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. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > 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. > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > 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. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > 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. > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

From what I understand, the majority think this feature is useful in the

> Am 15.02.2016 um 09:29 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: > > Do you mean to simply ignore the method? If we do (the current > non-portable solution of OWB and Weld) a user might be suprised why a > method invoked on a proxy does not reach the target instance (it will be > invoked upon a client proxy instance). Miserable default behavior I > believe. And this will happen for a client proxy for non-interface bean > types. Technically that is afaik the only possible option we do have as long as we don’t rewrite the bytecode of the _original_ class. And that might be pretty hard to do for classes coming from the JDK for example ;) As Jens perfectly nailed it: a.) The user explicitly declares „Yes, I know what I do and I’ll live with the consequences“ and b.) Those are most times protected or package-default methods. I think this will mostly happen with self-injection. And this will only happen to be a problem for CDI and NIV (as in ‚classic‘ EJBs you only can call ‚business methods‘ even for self injection. And business methods are always only public methods). Of course that is an important use case, which you really need from time to time. But how often does ‚Random Jo/anna‘ programmer use this? In my experience there is a balance of 1:10000 self-injection methods vs general CDI method. It’s mostly used by experts who know what they do. LieGrue, strub _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.

> - explicitly produced via @Produces There are other use cases beside produces e.g. @ApplicationScoped class MyClass extends ClassWithFinalMethods But if we add this as well, then there is no other use case left! You could also go on and remove the whole rule in that case. But that is exactly what we don’t like, right? Because Random Joe would fall into this trap way too easily. > - added explicitly via an extension Pretty hard for an average user to do. And would also trump backward compatibility. LieGrue, strub > Am 13.02.2016 um 22:21 schrieb David Blevins <david.blevins(a)gmail.com&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. > > High level, I agree with both Mark and Martin. > > - 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. > > - 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. > > That said, I’m not sure if this approach is workable in any way, but here goes: > > We keep the default rule of beans with final methods being unproxyable unless explicit action in code is taken and the class is: > > - explicitly produced via @Produces > - added explicitly via an extension > > 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. > > > Thoughts? Big holes in there? > > > -David _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 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.