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

From what I understand, the majority think this feature is useful in the

> Am 15.02.2016 um 09:29 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: > > Do you mean to simply ignore the method? If we do (the current > non-portable solution of OWB and Weld) a user might be suprised why a > method invoked on a proxy does not reach the target instance (it will be > invoked upon a client proxy instance). Miserable default behavior I > believe. And this will happen for a client proxy for non-interface bean > types. Technically that is afaik the only possible option we do have as long as we don’t rewrite the bytecode of the _original_ class. And that might be pretty hard to do for classes coming from the JDK for example ;) As Jens perfectly nailed it: a.) The user explicitly declares „Yes, I know what I do and I’ll live with the consequences“ and b.) Those are most times protected or package-default methods. I think this will mostly happen with self-injection. And this will only happen to be a problem for CDI and NIV (as in ‚classic‘ EJBs you only can call ‚business methods‘ even for self injection. And business methods are always only public methods). Of course that is an important use case, which you really need from time to time. But how often does ‚Random Jo/anna‘ programmer use this? In my experience there is a balance of 1:10000 self-injection methods vs general CDI method. It’s mostly used by experts who know what they do. LieGrue, strub _______________________________________________ cdi-dev mailing list cdi-dev(a)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.