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

Sat Feb 13 17:30:42 EST 2016

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160213/9cacf590/attachment.html 