For it to be part of the CXF CDI module ? Sure, if it can help to
improve it then yes, I'm not sure if activating it by default will work
for Romain, but please create PR and let Andriy and Romain comment
Thanks, Sergey
On 18/09/17 11:08, John D. Ament wrote:
Would you be in favor of having one checked in and used by default if
you're using CDI integration?
On Mon, Sep 18, 2017 at 4:41 AM Sergey Beryozkin <[email protected]>
wrote:
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/
