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

Sat Feb 13 18:04:36 EST 2016

> Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau <rmannibucau at gmail.com>:
> 
> 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.

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. 

@David: 
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.
We probably would also need to extend the SPI in that case to allow Extensions to have full control.

One more thing:
This also hits already existing apps which move from Java6 to 7/8. I’m fine with supporting those on a non-portable basis.

@John
> 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.
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. 

LieGrue,
strub

> Am 13.02.2016 um 23:30 schrieb Romain Manni-Bucau <rmannibucau at gmail.com>:
> 
> 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.
> 
> Le 13 févr. 2016 23:25, "John D. Ament" <john.d.ament at gmail.com> a écrit :
> Some comments in line.
> 
> On Sat, Feb 13, 2016 at 4:22 PM David Blevins <david.blevins at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.