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

Sat Feb 13 17:24:32 EST 2016

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