Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods
We should follow a pattern closer to EJB (in my opinion) where the
non-proxyable methods are just not proxied - you won’t get transactions, etc available.
But that’s exactly what it does!
If you have an EJB NIV then final methods are allowed and you don’t even get a warning.
But if the user invokes this method then unforseeable things happen because the invocation
will end up on the proxy instance and not on the internally delegated instance. That’s the
reason why we have the UnproxyableResolutionException which you will _normally_ get for
this cases in CDI. In that case the first thing to do is to remove the ‚final‘ modifier
from this method.
But sometimes the developer simply doesn’t have any chance! For example if the classes to
proxy are from a 3rd party library or even from the JDK itself!
For those cases we now have a way to let the developer declare ‚omg, I know it’s bad, but
I need to do this anyway but I only add an exclusion to the rule for this very class!‘
txs and LieGrue,
strub
Am 10.02.2016 um 13:48 schrieb John D. Ament
<john.d.ament(a)gmail.com>:
+1 for adding this feature to the spec.
-1 for adding it the way it is written currently. This isn't to say that Mark's
idea is bad, its just that it puts too much onus on the application developer to know the
structure of its classes, both internally developed and externally provided.
We should follow a pattern closer to EJB (in my opinion) where the non-proxyable methods
are just not proxied - you won't get transactions, etc available.
John
On Tue, Feb 9, 2016 at 11:37 AM Antoine Sabot-Durand <antoine(a)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(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.
_______________________________________________
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.