[jira] [Commented] (OWB-941) Signal or handle differently final methods

["Tobias Stoeckmann (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OWB-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13968687#comment-13968687 ] 

Tobias Stoeckmann commented on OWB-941:
---------------------------------------

I can see the reasoning not to allow final methods and if it's part of the specification, I cannot argue against that. So it's just a question to verify ...

Does it mean that I am not allowed to inject a ThreadPoolExecutor (anymore)? We have an extended ThreadPoolExecutor that we used to inject, ApplicationScoped. This is not possible anymore because the ThreadPoolExecutor has final methods.

Is there a way to circumvent this? Or do I have to write an adapter class?

> Signal or handle differently final methods
> ------------------------------------------
>
>                 Key: OWB-941
>                 URL: https://issues.apache.org/jira/browse/OWB-941
>             Project: OpenWebBeans
>          Issue Type: New Feature
>          Components: New Features
>    Affects Versions: 1.2.2
>            Reporter: Ludovic Pénet
>            Assignee: Mark Struberg
>            Priority: Minor
>              Labels: features
>             Fix For: 1.2.3
>
>
> OWB does not properly handle final methods of classes.
> That leads to strange bugs, like discussed on this thread http://mail-archives.apache.org/mod_mbox/deltaspike-users/201403.mbox/browser
> In this case, there is
> public class Base implements Serializable {
>     public final List getValues() { ... }
> }
> @Named
> @ViewAccessScoped
> public class DerivedFromBase extends Base {
> }
> In my case, the method was called on the proxy rathered that on the base class when called through an EL expression like #{derivedFromBase.values}
> It would be nice if OWB would
> 1) scream if it encounters a "final" method. Refusing to create a proxy might be a bit harsh. Just not proxying the "final" method along with a log might be better (and easier to debug)
> or better
> 2) handle differently final methods



--
This message was sent by Atlassian JIRA
(v6.2#6252)