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

[Mark Struberg]

Sure, let’s extend the period but also please let’s actively evalutate all viable alternatives. The more options we have the better the solution will potentially be. 

Thinking about the BusinessMethod proposal a bit:

.) it is surely better in the sense that it does not go down the rabbit hole of implementation details with the JVM

.) it might be more complex to configure. At the end you inverses the allowProxying configuration from an ‚exclude class‘‚ to an ‚include business methods’, right? Might be a bit much to configure. But let’s first check how that might look like for the users.

LieGrue,
strub


> Am 12.02.2016 um 18:19 schrieb Antoine Sabot-Durand <antoine at sabot-durand.net>:
> 
> 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.
>