+1
(even though I can live with a portable alternative approach to the current PR)
So far I did not express my support for this PR even though I promised to do so. Unable to
proxy those classes is a major issue to me while migrating old software to a newer
environment.
As soon as you deal with 5 to 10+ years old software and try to migrate your large
application step by step you will encounter framework base classes with (protected) final
methods. CDI, @Inject and interceptors help a lot to cleanup the old stuff, however I have
to extend (currently unproxyable) framework base classes to do so. Example: I have to
extend AbstractFrameworkXyzAction with public and/ or protected final methods to implement
use case logic, and the derived classes should be CDI beans.
On the other hand - changing the old jar's is not an option either.
With this feature I can stop copying the modified base classes to my local archive (mostly
.war) in order to override the old classes.
Jens
Von: <cdi-dev-bounces@lists.jboss.org<mailto:cdi-dev-bounces@lists.jboss.org>>
on behalf of Antoine Sabot-Durand
<antoine@sabot-durand.net<mailto:antoine@sabot-durand.net>>
Datum: Tuesday 9 February 2016 17:36
An: CDI-Dev <cdi-dev@lists.jboss.org<mailto:cdi-dev@lists.jboss.org>>
Betreff: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private
final methods
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