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

Romain Manni-Bucau rmannibucau at gmail.com
Mon Feb 15 04:35:06 EST 2016


Re-browsing this thread I think several +1 were "we need something and we
didn't get anything better yet".

The late proposal of a annotation and more important a SPI sounds to me a
nice alternative since it allows to make broken code working back without
modifying the application code (or even the war itself). Sounds also less
hacky than a system property and portable.

Would it be possible to evaluate this proposal as a replacement before
closing this vote?



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2016-02-15 10:16 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

> 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 at redhat.com> 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 at gmail.com
>> > <mailto: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.
>>
>> 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 at sabot-durand.net <mailto: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
>> >>     <mailto: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
>> >>         <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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.
>> >
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>> _______________________________________________
>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160215/f0ce06a6/attachment-0001.html 


More information about the cdi-dev mailing list