<p dir="ltr"><br>
Le 14 févr. 2016 00:04, "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> a écrit :<br>
><br>
> > Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
> ><br>
> > You can also extend 3rd party classes - no producer but same constraint - so needs to be global - ie not limited to producers - or doesnt help.<br>
><br>
> I also think it should be an option which is not only required for producer methods but more generic. Also extending a 3rd party class in a bean archive creates this restriction.<br>
><br>
> @David:<br>
> that comes pretty close to my original proposal to have a @AllowProxying anntation on the producer field/method or managed bean. I like Pete’s last comment and we of course could also simply rename this to @ContainsNonBusinessMethods or something similar. It would avoid the term ‚proxy‘ which some people seem to think is too low level. But I thin that not many user would grasp what that does in the end. It’s not as self-explaining as @AllowProxying imo.<br>
> We probably would also need to extend the SPI in that case to allow Extensions to have full control.<br>
><br>
> One more thing:<br>
> This also hits already existing apps which move from Java6 to 7/8. I’m fine with supporting those on a non-portable basis.<br>
></p>
<p dir="ltr">If in a SPI we can probably accept to write a custom "migration" Extension then. Important is to not touch existing codebase.</p>
<p dir="ltr">> @John<br>
> > 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.<br>
> That could be a good thing to do. Of course it only is possible if the interceptor is applied on a method and not on the whole class. In the later case the final methods would simply not work on the proxy.<br>
><br>
><br>
> LieGrue,<br>
> strub<br>
><br>
><br>
> > Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
> ><br>
> > You can also extend 3rd party classes - no producer but same constraint - so needs to be global - ie not limited to producers - or doesnt help.<br>
> ><br>
> > Le 13 févr. 2016 23:25, "John D. Ament" <<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>> a écrit :<br>
> > Some comments in line.<br>
> ><br>
> > On Sat, Feb 13, 2016 at 4:22 PM David Blevins <<a href="mailto:david.blevins@gmail.com">david.blevins@gmail.com</a>> wrote:<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>
> > Sounds like a not too responsive UI. I wonder if Atlassian has a test for 36 comments. XD<br>
> ><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>
> > 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.<br>
> ><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>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><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>
> >> On Feb 12, 2016, at 9:19 AM, Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>> wrote:<br>
> >><br>
> >> Hi Guys,<br>
> >><br>
> >> Some EG members (like David Blevins) asked to have until the ned of the week-end to vote here.<br>
> >> 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.<br>
> >><br>
> >> Regards,<br>
> >><br>
> >> Antoine<br>
> >><br>
> >> Le ven. 12 févr. 2016 à 17:23, Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> a écrit :<br>
> >> Sure, that might probably be a viable way to do it.<br>
> >><br>
> >> Oki, here are the two use cases which we need to solve:<br>
> >><br>
> >> 1.)<br>
> >> @Produces<br>
> >> @ApplicationScoped<br>
> >> public SomeWeirdThirdPartyClassWithFinalMethods createIt() {return …};<br>
> >><br>
> >> 2.)<br>
> >> @ApplicationSCoped<br>
> >> public class MySubclass extends SomeWeirdThirdPartyClassWithFinalMethods {}<br>
> >><br>
> >> Any other use case?<br>
> >><br>
> >> Can you please elaborate how your idea will look like? Just a few ideas so we can get it running.<br>
> >><br>
> >> txs and LieGrue,<br>
> >> strub<br>
> >><br>
> >><br>
> >> 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>
> >><br>
> >><br>
> >><br>
> >> > Am 12.02.2016 um 17:12 schrieb Pete Muir <<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>>:<br>
> >> ><br>
> >> > -1<br>
> >> ><br>
> >> > The problem seems real, but proposed approach doesn't sit right with<br>
> >> > me. I think it would be better to follow the EJB approach, and add a<br>
> >> > way to be able to declare a method as "not a business method" (a<br>
> >> > business method is also a thing in CDI IIRC).<br>
> >> ><br>
> >> > For example, e.g. using beans.xml and an annotation. This then allows<br>
> >> > the spec to consistently treat this public method as not a business<br>
> >> > method.<br>
> >> ><br>
> >> > On 9 February 2016 at 16:36, Antoine Sabot-Durand<br>
> >> > <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>> wrote:<br>
> >> >> Hi all,<br>
> >> >><br>
> >> >> There have been a lot of discussion around CDI-527 in the last weeks:<br>
> >> >> <a href="https://issues.jboss.org/browse/CDI-527">https://issues.jboss.org/browse/CDI-527</a><br>
> >> >><br>
> >> >> Mark proposed a PR:<br>
> >> >> <a href="https://github.com/cdi-spec/cdi/pull/271">https://github.com/cdi-spec/cdi/pull/271</a><br>
> >> >><br>
> >> >> But we don't agree on adding this feature to the spec.<br>
> >> >> This vote is to decide if we should add this feature at the spec level now,<br>
> >> >> or not.<br>
> >> >> Should we vote this feature down, that won't mean it will be completely<br>
> >> >> dropped: it could be implemented as non portable feature in both Spec or<br>
> >> >> even be included as experimental feature in the spec (in annexes) as<br>
> >> >> describe in the PR comments<br>
> >> >> Vote starts now, only vote from EG members are binding (but you can give<br>
> >> >> your opinion if not part of the EG) and will last 72 hours.<br>
> >> >><br>
> >> >> You vote with the following values:<br>
> >> >> +1 : I'm favorable for adding this feature in the spec<br>
> >> >> -1 : I'm against adding this feature in the spec<br>
> >> >> 0 : I don't care<br>
> >> >><br>
> >> >> Thank you for your attention and your vote.<br>
> >> >><br>
> >> >> Antoine Sabot-Durand<br>
> >> >><br>
> >> >> _______________________________________________<br>
> >> >> cdi-dev mailing list<br>
> >> >> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> >> >> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">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<br>
> >> >> under the Apache License, Version 2<br>
> >> >> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
> >> >> provided on this list, the provider waives all patent and other intellectual<br>
> >> >> property rights inherent in such information.<br>
> >> > _______________________________________________<br>
> >> > cdi-dev mailing list<br>
> >> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> >> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">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">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>
> >><br>
> >> _______________________________________________<br>
> >> cdi-dev mailing list<br>
> >> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">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">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>
> ><br>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">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">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>
> ><br>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">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">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>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">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">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>
><br>
</p>