[cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods
Martin Kouba
mkouba at redhat.com
Mon Feb 15 03:29:03 EST 2016
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
More information about the cdi-dev
mailing list