[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