[cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods

[Jens Schumann (JIRA)]

    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142608#comment-13142608 ] 

Jens Schumann commented on CDI-527:
-----------------------------------

The only situation where I have been running into this issue was integrating CDI in an existing framework, where the entry point to CDI should be as integrated as possible and therefore required extending a framework class with protected final methods. In other words: If you work with framework X you have to extend base class Y (e.g. a web framework action). To make most out of CDI I would love to have an CDI bean extending Y which failed due to the UnproxyableResolutionException. 

The biggest difference to what you discussed above is: I have to deal with lots of legacy code that should be migrated to a newer stack (slowly). Moving to CDI and CDI interceptors (\@Transactional) requires to work with 10+ years old code, that uses base classes and protected final methods a lot. I have never had an issue with java.* or javax.* being Unproxyable so far.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)