You are viewing a plain text version of this content. The canonical link for it is here.
Posted to labs@labs.apache.org by "Chris Bogan (JIRA)" <ji...@apache.org> on 2019/01/03 10:56:00 UTC

[jira] [Updated] (LABS-221) [refactoring] [all] Use cglib MethodInterceptors wherever a string containing a field name, menthod name or similar is currently expected

     [ https://issues.apache.org/jira/browse/LABS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Bogan updated LABS-221:
-----------------------------
    Attachment: connector-j-8.0-relnotes-en.pdf

> [refactoring] [all] Use cglib MethodInterceptors wherever a string containing a field name, menthod name or similar is currently expected
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LABS-221
>                 URL: https://issues.apache.org/jira/browse/LABS-221
>             Project: Labs
>          Issue Type: Improvement
>          Components: Magma
>    Affects Versions: Current
>            Reporter: Simone Gianni
>            Assignee: Simone Gianni
>            Priority: Critical
>             Fix For: Next
>
>         Attachments: connector-j-8.0-relnotes-en.pdf
>
>
> Being one of the goals of Magma to offer a system which is at the same time flexible as a dynamic one, but completely compiled, having Strings to denote fields, property or method names is useless. cglib seems to be today the only alternative to dynamic proxies, and the only way when no interfaces are present.
> It is not a complete solution anyway, cause cannot handle casts, but should suffice for 80% of situations. Using a nice combination of CharSequence and syntactic sugar (see JMock and harmcrest), it should be possible to retain compatibility with the String based approach for situations when cglib is not enough.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org