My understanding ClassUnwrapper callback was added to support these
scenarios, Romain may've used it.
Sergey
On 17/09/17 23:27, John D. Ament wrote:
On Sun, Sep 17, 2017 at 5:09 PM Sergey Beryozkin <[email protected]>
wrote:
Hi
On 17/09/17 15:37, John D. Ament wrote:
Hey
So I just ran into an issue where ExceptionMappers weren't being
processed
in CXF when they had a CDI normal scope. Switching to a pseudo scope
(@Dependent) fixes it. A similar issue to what I saw recently with Weld
and Generic Type being lost, except this was happening for both OWB and
Weld.
While I was able to dig into the prior issue with generic type arguments,
that was a Weld specific issue. I couldn't figure out why CXF wasn't
reading the metadata of the actual bean class. I'm wondering if for CDI
use cases, if it makes sense for CXF to look at the actual class's
metadata, separate from the CDI instance that's being passed in (which is
just a proxy).
I think this is what is done for ex in the Spring case, is it not the
case in the CXF CDI flow ? When JAXRSServerFactoryBean.createFromBeans,
etc, is called then ClassResourceInfo would be initialized with the
'resource' class which may be the proxy, and the 'service' class which
is the actual class.
ClassHelper is used to find the actual 'service' class.
May be CXF CDI needs to use ClassHelper ?
Ok, so that answers a lot of questions (and I have a prototype fix!). So,
yes, CDI does in fact use ClassHelper to get the class in use. However, it
doesn't work for CDI. The methods in ClassHelper are based on Proxy, which
OWB and Weld do not use. LIkewise, the SpringAopClassHelper is based on
Spring specific proxies.
Funny thing is, I think my first question on this list was about
SpringAopClassHelper. I like how this has come full circle.
So now the prototype. Weld and OWB use a classname suffix to indicate
their proxies. Using that suffix, I can unwrap the parent class and get
things to work properly.
Now the question is - should this be in the core ClassHelper, or should I
use ClassUnwrapper which is mentioned in the getRealClass(Bus,Object)
method? I see that there's no implementations of ClassUnwrapper on the
classpath, so maybe its a dead code path?
I will caution you - I suspect that changing this may cause some existing
apps using CXF + CDI to behave a little differently, but I suspect I may be
the first one to run into these.
Sergey
John
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
