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

[Antoine Sabot-Durand]

Hi all,

Apparently, the preferred solution for CDI-527 is the first Mark proposed:
a dedicated annotation.
Since we are introducing an annotation dedicated to proxy perhaps we should
think it in a more general proxy configuration way to be used for other
tickets like CDI-414 [1]

That would give something like:
@ProxyConfig(force=true) to force proxy even if the class has final method
and
 @ProxyConfig(force=false, self=true) to have internal code in the bean to
be intercepted / deocrated

wdyt

[1] https://issues.jboss.org/browse/CDI-414


Le mar. 16 févr. 2016 à 17:56, Mark Struberg <struberg at yahoo.de> a écrit :

> >    - explicitly produced via @Produces
> There are other use cases beside produces
> e.g. @ApplicationScoped class MyClass extends ClassWithFinalMethods
>
> But if we add this as well, then there is no other use case left!
> You could also go on and remove the whole rule in that case.
> But that is exactly what we don’t like, right?
> Because Random Joe would fall into this trap way too easily.
>
> >    - added explicitly via an extension
>
> Pretty hard for an average user to do.
> And would also trump backward compatibility.
>
> LieGrue,
> strub
>
>
>
> > Am 13.02.2016 um 22:21 schrieb David Blevins <david.blevins at gmail.com>:
> >
> > 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
>
>
> _______________________________________________
> 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/20160217/0255a864/attachment-0001.html