Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods

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.