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

Sat Feb 13 16:21:45 EST 2016

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.

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.

 - 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

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 <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 <https://issues.jboss.org/browse/CDI-527>
> >>
> >> Mark proposed a PR:
> >> https://github.com/cdi-spec/cdi/pull/271 <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 <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 <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 <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 <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/b8061822/attachment.html 