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@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@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@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.