cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Romain Manni-Bucau (JIRA)" <>
Subject [jira] [Commented] (CXF-7229) ClassHelper usages not replacable by ClassUnwrapper
Date Fri, 27 Jan 2017 13:03:24 GMT


Romain Manni-Bucau commented on CXF-7229:

[~sergeyb] well the MBW impl could do it...means they ALL need to have the support for ALL
possible proxies. CXF introduces Class[Unwrapper|Helper] concept to ensure you can set it
and integrate with any 3rd party frameworks transparently. I think it is an awesome CXF feature
and would be very beneficial there. Worse case the unwrapping is very cheap (getClass().getName().contains("...")
only) and doesn't affect perf but it enables several cases so I still think it does worth
it. Side note: this issue is more about the consistency of the unwrapper usage (which is a
SPI vs the hardcoded helper), the other one is about the unwrapping need.

> ClassHelper usages not replacable by ClassUnwrapper
> ---------------------------------------------------
>                 Key: CXF-7229
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>            Reporter: Romain Manni-Bucau
>            Assignee: Andriy Redko
>         Attachments: proxy-test-case.txt
> ClassUnwrapper and ClassHelper are pretty close and for an app setting a single one should
be enough (in particular cause ClassHelper overriding is hacky)
> Spotted org.apache.cxf.jaxrs.utils.InjectionUtils#getRawResponseClass for instance

This message was sent by Atlassian JIRA

View raw message